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(57) Abstract: Apparatus, lystems and methods are provided for integrating data stored using legacy Data Base Management Sys- 
tems (sometimes referred to herein as "legacy data") with data that Is accessible through a global communications network environ- 
ment (somedmes referred to herein as "Internet data") such as the Internet A server provides a structured process for efiScient data 
flow through incoming document transformation, implementation of business rules, and response document routiog. Legacy and 
Internet data aie conveited and kitegrated, without loss, using intermediate data structures encapsulated within software objects with 
exposed methods for cteatioii, navigation, maintenance, and accessing of data within the software objects. These software objecU 
may also be used for develof^g, managing, conti^ng and integrating Internet data from within any ITI^ndows sci^isg hosled 
language, including amcmg others, VB (>^sual Basic) Script, JScript, and P^ilScript In an alternative embodiment, a legacy data 
Internet portal is provided for legacy application software systems integration with a global communications network such as thi& 
Internet that exposes the ability to execute a method on a legacy database server using an bitemet application on a Web server. The 
results of the execu te d method are returned to the Web server as a txee-based Internet data structure. 
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APPARATUS, SYSTEMS AND METHODS FOR ELECTRONIC DATA 
DEVELOPMENT, MANAGEMENT. CONTROL AND INTEGRATION IN A GLOBAL 
COMMUNICATIONS NETWORK ENVIRONMENT 



BACKGROUND OF THE INVENTION 

Pre-Intemet era businesses are struggling to integrate their businesses and existing legacy 
systems with the global conununications network known as the Internet. (Many businesses 
originated in the pre-Intemet era and automated their respective data processing needs prior to 
the development and wide-spread acceptance of the Internet These pre-Intemet systems are often 
referred to as legacy systems. Other entities have busmesses that revolve primarily around the 
Internet; typically, such businesses originated during or after the dawning of the Internet age and 
are sometimes referred to herem as "Intemet-era businesses**)- Intemet-era businesses are 
stmggling with unrefined tools to develop, manage and control data collected and processed with 
their Internet-based systems. Both Pre-Intemet era and Internet-era businesses are stmggling to 
conununicate with one another. 

In some cases, the data structures used by legacy systems are not directly compatible with 
Internet data stmctures. Consequently, many enterprises with legacy systems face the task of 
converting data created and stored by their respective legacy systems to a form cognizable by 
Internet based systems for their respective emergence into electronic conunerce (eCommerce), 
and for their ixxterfacc vdth their respective Internet trading partners. 

Additionally, eConmierce mc^ comprise only a portion of an enterprise's entire business. 
Accordingly, data collected and processed on the Internet must be integrated with the data 
maintained on the enterprise's legacy systems. 

Most automated systems, whether legacy or Internet, use some architectural scheme, 
which is expressed in a particular data structure, to organize the system's data. There are many 
different types of data structures. Legacy systems fi-equently use hierarchical or multivalued 
simple data structures with which to organize their respective data. Some legacy systems use 
relational simple data database management systems. In contrast to the data structures used by 
legacy systems, tree-based rich data stmctures comprise much of the data foundation for the 
Internet. 

In contrast to the explicit organizational and descriptive intelligence contained in rich data 
structures, the organization and meaning of data items in simple data structures are often inherent 
to die order of the data, and/or require the intelligence of vAiat is known as metadata or an 
application program to identify the begiiming and end of, and impart meaning to, individual data 
items. 

Metadata is data about data - it is high level data about the lower-level data contained in 
a particular file or data base. In some cases, such as is the case with multivalued data structures, 
low level metadata is implicit in the data which it describes. In other cases, such as is the case 
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with ceitain Data Base Management Systems (DBMS), metadata describing the data base is 
contained within a data dictionary. Other examples of metadata include: record descriptions in 
a COBOL program, CASE entity relationship diagrams for a particular set of entities, and data 
server catalog logical view descriptions. 

As a consequence of the absence of explicit metadata in simple data structures, conversion 
to tree-based rich data structures based on the source data alone may result in data loss. 

In a txee-based rich data structure, a root node, also referred to as a mother or parent node, 
describes the most basic level of information about the data to which the root node pertains. For 
instance, a document level node is used to describe a document Other nodes, referred to as 
"child** or ''children** nodes, can be designated with some relation, either direct or indirect, to the 
root node. For instance, the root node may have one or more child nodes, each of which in turn 
has one or more child nodes, each of which in turn has multiple children nodes. 

One of the predominant tools for the development and exchange of data in Internet-based 
systems is Extensible Markup Language (XML). XML was originally designed as a markup 
language for electronic documents. A mark up language such as XML uses certain defined 
delimiters and tag names to designate meaning and/or organization of marked text within an 
electronic document. As an example, a sample electronic document has as its title the words 
''This is the Title*' and has as a single paragr^h of text "This is the text'* Using an exemplary 
mark up language to mark up the electronic document, a start title delimits/tag name (in this 
example, "<t>**) is inserted before the title text for an electronic document; an end title 
delimiter/tag name (in this example, "</!>**) is inserted after die title text Similariy, a start 
paragr^h delimiter/tag name (in this example, ''<p>**) is inserted before the first letter of the first 
word of a particular paragraph; an end paragraph delimiter/tag name (in this example, "</p>**) 
is inserted after the last letter of the last word of the paragrq>h. The resulting marked up 
electronic document would be represented in memory as follows: 

<t>This is the Title </P^ 

<p> This is the texL</p> 

Internet development programmers have begun to use document markup languages, such 
as XML, to develop and exchange many types of data collections, other than merely electronic 
documents (electronic documents are sometimes referred to herein as simply "documents**). 
XML is used to identify structures in such diverse applications as metadata description, vector 
graphic manipulation, eCommerce, and mathematical equadon expression, to name just a few. 

In addition to being a mark up language, XML is also vAat is known as a "meta language** 
in that it provides for the explicit declaration of new Document Type Definitions (DTD) - that 
is, it provides development programmers with the ability to define program-specific tag names. 
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Because of the DTD declaration capability of XML, each business may independently develop 
its own XML structures and tags. A particular strategy for marking up a document with tag 
names, naming conventions, delimiters and/or document structures is refened to herein as a 
"mark up schema** or simply "schema". 

An electronic document, or other collection of data (data collection), that has been marked 
up, such as with XML delimiters and tag names, is referred to as a mariced up document; in the 
case of XML, as an XML document. Application programs are typically designed to access, 
navigate and manipulate marked up documents in tree-based form. Application programs access 
XML documents through a Document Object Model (DOM). A DOM is a machine-readable 
tree-based representation of an XML document A type ofprogram sometimes referred to as a 
document parser (in the case of XML, as an XML parser) provides a translation interface betwera 
the marked up document and the machine readable tree-based representation of that marked up 
electronic document. 

The structural elements and DTD cq)abilities of XML and DOM enable the development 
of tree-based rich data structures. Notwithstanding the fact that many Intemet developers are 
using XML and other mark up languages to define data structures for Intemet applications, the 
tools, such as DOM, that are available to create, navigate and maintain tree-based rich data 
stmctures are cumbersome and difiGcult to use. 

^thout specially designed technology, the job of converting data without data loss from 
legacy systems to Internet-cognizable tree-based data structures can be a complex, resource- 
intensive project for any company tackling the job; the job is one that, with existing tools, 
requires highly-detailed, fact-specific program coding. Furttiermore, without better, more 
effective tree-based rich data structure navigational tools, the creation, navigation, maintenance, 
and accessing of data between multiple Intemet enterprises will remain difficult and time 
consuming. 

Technology is therefore required to facilitate the resource efficient conversion of data 
created by legacy systems to a form useful to Internet-based programs and to facilitate the 
integration of the converted data with data existing in the Intemet environment. Technology is 
further required to facilitate the resource efi^cient conversion of Intemet data to simple data 
stmctures with ^ich legacy systems can communicate and to facilitate the integration of die 
converted data with existing legacy system data. Technology is still further required to fecilitate 
the resource efficient creation, navigation, maintenance, and accessing of data between multiple 
Intemet enterprises. 

Another aspect of Lega^-Intemet transitions is the investment many companies have 
made in their respective legacy systems. Companies that have made such an investment and 
which also want to gain the benefits of the latest Intemet technology, marketing and business 
opportunities, need a way to leverage the existing legacy system application software. 
Accordingly, some means is required that can expose (the term "expose^ is used herein to mean 
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''make available for access'*, "make accessible** and/or "access**) the software capability and 
functionality of legacy system application software, 

SUMMARY OF THE INVENTION 

The present invention provides apparatus, systems and methods for integrating data stored using 
legacy Data Base Management Systems (sometimes referred to herein as "legacy data**) with data 
that is accessible through a global communications network environment (sometimes referred 
to herein as "Internet data**) such as the Internet 

One aspect of die present invention provides apparatus, systems and methods for 
converting and integrating, without data loss, legacy data to an Internet data structure, such as a 
tree-based rich data structure. In one embodiment, the present invention provides a method, 
using a computer, for converting source data to an Internet data structure. The Internet data 
structure is characterizable by a tree-based structure definition. The source data to be converted 
is characterized by a particular structure and by a set of relationships. The structure and the set 
of relationships that characterize the source data are described by metadata which comprises a 
plurality of metadata components. The metadata and the metadata components are accessible by 
the computer. 

The method to convert the source data to the Internet data structure comprises sevml 
stqis. The computer translates the metadata into a set of DTD declarations and a 
corresponding tree-based structure definition. If the metadata is not in a form readily accessible 
by the computer, then the first step is to translate the metadata into a form that is readily 
accessible by the computer. 

The computer develops a conversion map comprised of equivalent DTD declarations and 
the corresponding metadata component and ftirther comprised of equivalent node definition and 
the corresponding metadata component. The computer then uses the conversion map to map the 
source data into the Intemet data structure. 

Yet another aspect of the present invention provides ^paratus, systems and methods for 
converting and integrating, without data loss, Intemet data to a legacy data structure. In one 
embodiment, the present invention provides a method, using a computer, for converting Intemet 
data to a simple legacy data structure. The Intemet data structure is characterized by a tree-based 
strocture definitioiL The legacy data structure is characterized by a particular structure and by a 
set of relationships. The structure and the set of relationships that characterize the legacy data aie 
described by metadata vMch comprises a plurality of metadata components. The metadata and 
the metadata components are accessible by the computer. ^ 

The method to convert the Intemet data to the legacy data structure comprises several 
steps. The computer translates the metadata into a set of DTD declarations and a 
corresponding receiving tree-based structure definition. The receiving tree-based structure 
definition comprises a plurality of receiving node definitions. Each DTD declarafion is equivalent 
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to one of the metadata components. Each of the receiving node definitions is equivalent to one 
of the metadata components. 

The computer stores each equivalent DTD declaration and the corresponding metadata 
component as a conversion map components. The computer stores each equivalent receiving 
node definition and the corresponding metadata component as a conversion map component The 
computer then aggregates the conversion map components into a conversion map. The computer 
uses the conversion map to create a recei^ng tree-based structure. 

The computer then compares the Internet data tree-based structure with the receiving tree- 
based structure. For each node in the Internet data tree-based structure, the computer identifies 
the equivalent receiving tree-based structure node. The computer builds a translation table of the 
equivalent Internet data tree nodes and the corresponding receiving tree nodes. The computer 
uses the translation table to map the Internet data to the receiving tree-based structure. Then, 
using the conversion map, the computer translates the data in the receiving tree-based structure 
into the legacy data structure. 

Yet another aspect of the present invention provides apparatus, systems and methods for 
the resource efficient creation, navigation, maintenance, and accessing of data between midtiple 
Internet enterprises. In one embodiment, the present invention provides a method, using a 
computer, for converting Internet data fiom one Internet data structure to another Internet data 
structure . The first Internet data structure is characterized by a tree-based structure definition . The 
second Internet data structure is characterized by a second tree-based structure definition. 

The mettiod for converting Internet data fi:om one Internet data structure to another 
Internet data structure comprises several steps. The first tree-based structure definition comprises 
a first plurality of node definitions. The second tree-based structure comprises a second plurality 
of nodes. 

The computer compares the first Internet data tree-based structure with the second tree- 
based structure. For each node in the first Internet data tree-based structure, the computer 
identifies the equivalent node in the second tree-based structure. The computer builds a 
translation table of the equivalent first Internet data tree nodes and the corresponding second 
Internet data tree nodes. The computer uses the translation table to map the first Internet data to 
the second Internet data tree-based structure. 

Still another aspect of the present invention provides apparatus, systems and methods for 
developing, managing, controlling and integrating Internet data from witiiin any Windows 
Scripting Hosted language, including among others, VB (Visual Basic) Script, JavaScript, 
Po-lScript, and others using a simplified dot nodepath notation that provides for dynamic 
changes, additions and deletions of data nodes without the need for intervening compilation 
steps. 

A finther aspect of the invention is an Electronic Portal for Legacy Line-of-Business 
application software systems integration with a global communications network such as the 
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Internet This Electronic Portal exposes the ability to execute a command on a Legacy Line-of- 
Business database server using an Internet application on a Web server. The results of the 
executed command are returned to the Web server as an Internet data structure. 



BRIEF DESCRIPnON OF THE DRAWINGS 

These and other features, aspects, and advantages of the present invention will become 
better understood with regard to the following description, appended claims, and accompanying 
drawings ^ere: 

FIG. la is a deployment diagram of and exemplary dq)loyment across multiple host 
computers of an exemplary Intemet based system for accessing legacy data; 

FIG. 1 b is a high leve 1 diagram of the use of a legacy data to Intemet data adapter used to 
access a single legacy database; 

FIG. 2 is a diagram of the architecture of an exemplary general purpose computer capable 
of serving as a host for the software objects depicted in FIG. la; 

FIG. 3 is a sequence diagram of an exemplary communication sequence between the 
software objects of FIG. 1 ; 

FIG. 4 depicts data flow diagrams for exemplary legacy data adapter and Intemet data 
translator objects; 

FIG. 5 is a depiction of an exemplary DOM object encapsulating a DOM and exposing 
methods for operations on the DOM; 

. FIG. 6a is a class diagram for a business serven 

FIG. 6b is a data flow diagram illustrating intake of documents from the Web by the 
business server; 

FIG. 6c is a dataflow diagram of data through a business server, 
FIG. 6d is a data flow diagram of the operations of a sorter object according to the present 
invention; 

FIG. 6e is an exemplary business server XML document; 

FIG. 6f is an exemplary pipeline XML document as used by a dispatcher; 

FIG. 7 is a cooperation diagram depicting the operations in business server during an 
exemplary business transaction; 

FIG. 8 is a graphic representation depicting the structural element wrapping architectural 
feature of ttie invention; 

FIG. 9 provides a simplified, high level flow diagram depicting an exemplary embodiment 
of exemplary legacy data to Intemet data conversion program logic flow; 

FIGS. 10 and 1 1 depict typical invoice data represented in a hierarchical manner; 

FIG. 12 depicts an exemplary XML structure of typical invoice data; 

FIG. 13 is a formatted representation of an invoice record in an exemplary legacy data 
structure; 



wo 01/33387 PCT/CAOO/01280 

FIG. 14 is a representation of the way in the record depicted in FIG. 13 is stored in 
memory; 

FIGS. 1 5 and 1 6 are a representation of the equivalent Internet data structure of the data 
record depicted in FIG. 14; 

FIG. 17 depicts exemplary Visual Basic code that executes an exemplary syntax of a 
LoadDOM method in an exemplary embodiment of the invention; 

FIG. 18 depicts exemplary Visual Basic code that executes an exemplary syntax of a 
validate method in an exemplary embodiment of tfie invention; 

FIGS. 19-22 depict exemplaiy XML fragments; 

FIG. 23 is a graphical representation of an exemplaiy tree-based rich data structure in an 
exemplary Internet data structure. 

FIG. 24 is a logic flow diagram depicting the functional logic of an exemplary 
embodiment of an ExtendedProperties method; 

FIG. 25 represents an XML document containing exemplary data; 

FIG. 26 depicts exemplary scripting language program code using the dot nodepath 
notation aspect of the invention; 

HG. 27 is a logic flow diagram depicting the functional logic of an exemplary 
embodiment of the Node collection retrieval feature of the invention; 

FIG. 28 depicts exemplaiy Visual Basic code that executes an exemplaiy syntax of an 
exemplary embodiment of the Node collection retrieval feature of the invention; 

FIG. 29 is a logic flow diagram dq)icting the fmu^tional logic of an exemplary 
embodiment of die Node namepath inteipretation feature of the invention; 

FIG. 30 is a block diagram depicting the relationships between a three-tier system 
architecture using the Electronic Portal aspect of the invention; 

FIG. 31 depicts an exemplary Legacy method and an exemplary response in an 
exemplary Legacy Line-of-Business software application system; 

FIG. 32 depicts an exemplary Legacy data Intemet portal method using XML; 

FIG. 33 depicts the ou^ut of an exemplary Legacy data Intemet portal method; 

FIG. 34 is a logic flow diagram depicting the functional logic of an exemplary 
embodiment of tl^ Create a Q-Pointer feature of the invention; 

FIGS. 35 and 36 are graphic representations of interactive online display graphic user 
Q-Pointer interface features of fhe invention; 

FIGS. 37 and 38 are grsq[)hic representations of interactive onlme (tisplay graphic user 
Q-Pomter interface features of the invention; 

FIG. 39 is a logic flow diagram depicting the functional logic of an exemplaiy 
embodiment of the GetFile feature of the invention; 

FIG. 40 is a graphic representation of an interactive online display graphic user GetFile 
interface feature of the invention; 
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FIG. 41 is a graphic rq)resentation of a URL resulting fiom user entry of GetFile 
specification information; 

FIG. 42 depicts exemplary code embodying Retrieval Logic functions involved in 
Specifying the Nature of a GetFile Request; 

FIG. 43 is a graphic representation of an interactive online display graphic user GetFile 
specification interface feature of the invention; 

FIG. 44 depicts exemplary code embodying Retrieval Logic functions for Retrieving 
GetFile Data; 

FIG. 45 is a graphic representation of an interactive online display graphic user Getltem 
interface feature of the invention; 

FIG. 46 is a graphic data hierarchy diagram depicting an exemplary representation of an 
exemplary Relational Database Management System configuration. 

DETAILED DESCRIPTION OF THE INVENTION 
Server Architecture 

FIG. 1 is a deployment diagram of an exemplary implementation of a system facilitating 
the use of legacy data within Internet based transactions. The deployment diagram depicts a 
network of software objects with each software object deployed on a host. Each host is a 
general purpose conq)uter as depicted in FIG. 2. 

FIG. 2 is a hardware architecture diagram of a general purpose computer suitable for use 
as a software object host. Microprocessor 3600, comprised of a Central Processing Unit (CPU) 
3610, memory cache 3620, and busr interface 3630, is operatively coupled via system bus 3635 
to main memory 3640 and I/O control unit 364S. The I/O interface control unit is operatively 
coiq)led via I/O local bus 3650 to disk storage controller 3695, video controller 3690, keyboard 
controller 3685, and communications device 3680. The communications device is adapted to 
allow software objects hosted by the general purpose computer to communicate via a network 
with other software objects. The disk storage controller is operatively coupled to disk storage 
device 3625. The video controller is operatively coupled to video monitor 3660. The keyboard 
controller is operatively coupled to keyboard 3665. The network controller is operatively 
coupled to conununications device 3696. 

Computer program instructions implementing a software object are stored on the disk 
storage device until the microprocessor retrieves the conq^uter program instructions and stores 
them in the main memory. The microprocessor then executes the computer program 
instructions stored in the main memory to implement the software object 

Alternatively, other types of general purpose computers are used to host a business 
server. For example, the business server may be hosted by Personal Digital Assistants (PDAs) 
or computer systems dedicated to hosting Internet servers. 

Referring again to FIG. 1, business host 1096 hosts business server 1015 and is 



wo 01/33387 PCT/CAOO/01280 

operatively coupled to local area network 1080 via business conununications link 1020. The 
business communications link is adapted to support various conununications protocols based 
on the Transport Control Protocol/Internet Protocol (TCP/IP) such as Hyper Text Transfer 
Protocol (HTTP), Simple Mail Transfer Protocol (SMTP) and File Transfer Protocol (FTP) 
among others. The business server uses the software services and hardware links provided by 
the business host to conmiunicate with other software objects across the local area network and 
the Internet Database host 1076 hosts database server 1075 and is operatively coupled to the 
local area network via database link 1078. The database server provides access to Internet 
database 1010 and legacy database 1000. The business server stores and retrieves data firom the 
Internet database and the legacy database using services provided by the database server The 
legacy database contains data accessible in a format not normally suited for Intemet 
applications. The business server provides services to Intemet based clients to retrieve, 
manipulate, transmit, and store legacy data using the database server. Other databases 
accessible to the business server, such as the Intemet database served by the database server, 
contain dociunents suitable for transfer over the Intemet using one of the suite of Intemet 
communications protocols such as HTTP or SMTP. The business server and the database 
server communicate to each other via the local area network. 

Firewall host 1086 hosts firewall 108S. The firewall host is operatively coupled to the 
local area network via internal firewall conomunications link 1070. The internal firewall 
communications link is adapted to support various communications protocols based on TCP/DP 
such as HTTP, SMTP, and FTP, among others. The firewall host is operatively coupled to 
Intemet 3 via external firewall communications link 1090. The external firewall 
commimications link is adapted to support various communications protocols based on TCP/IP 
such as HTTP, SMTP, and FTP, among others. The Intemet is commonly called the World 
Wide Web (WWW or Web) vAim software objects conununicate to each other over the Intemet 
using one of a suite of communications protocols based on TCP/IP such as HTTP. In 
alternative embodiments, the Internet may be replaced using any computer network system 
capable of supporting electronic document transfers such as a local area network or a virtual 
proprietary network. 

The firewall filters incoming Intmiet data packets to ensure that only data packets for 
specified communications protocols are passed fipom the Intemet to the local area network. The 
business server conmiunicates witii software objects over the Intemet through the firewall using 
a variety of communications protocols for communication. Exemplary conmiunications 
protocols are: HTTP used for the transfer of documents written m one of various marie up 
languages such as Hyper Text Maricup Language (HTML) or XML; Simple Mail Transfer 
Protocol (SMTP) for the transfer of electronic mail (email) messages; and File Transfer 
Protocol (FTP) for the transfer of text and binary files. 

An exemplary software object capable of sending messages to the busuiess server via the 
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Interact is exemplary partner server 1 030. The partner server is hosted by partner host 1 032 that 
is operatively coupled to the Internet via partner communications link 1025^ The partner 
communications link is adapted to siipport various communications protocols based on TCP/IP 
such as HTTP, SMTP, and FTP, among others. In operation, the business server and the partner 
server request and send data to each other over the Internet. For example, the partner server 
may send an Internet document composed in XML to the business server. The content and 
structure of the XML document may be decomposed by the business server to create 
instructions for a purchase order. This purchase order may require the updating of the legacy 
database and retrieval of an Interact document from the Internet database. The retrieved 
Interact document is sent by the business server back to the partner server as an order 
acknowledgment Any business transaction involving the transfer of data may be unplemented 
so long as the business server and the partner server agree on the appropriate data structure and 
communications protocol. 

Business server 1015 may also communicate over the Internet to other software objects. 
The business server may send email messages to email server 1 045 hosted by email server host 
1 046 using SMTP as the communications protocol The email server host is opemti vely coupled 
to the Internet via email server communications link 1040. The email server commimications 
link is adapted to siq)port mail communications protocols based on TCP/IP such as SMTP and 
Post OfGce Protocol (POP). The email messages are held by the email server until they are 
retrieved by email client 1060 hosted by email client host 1062. The email client host is 
operativelycoupledtothelntemetviaemailclientcornmuiiicatioiisliiik 1065. The email client 
conununications link is ads^ted to support various communications protocols based on TCP/IP 
such as POP. The business server uses email messages to send informational messages about 
the operations of the business server. For example, the business server may send an email 
message to the email server to acknowledge a purchase order or to alert a customer that a 
product is on back order. 

The business server may also send Internet documents over the Interact in response to 
requests from exemplary Web client 1055 using HTTP as the communications protocol. The 
Web client is hosted by Web client host 1056. The Web client host is opemtively coupled to 
the Interact via Web client conununications link 1050. The Web client communications livk 
is adapted to support varioiis communications protocols based on TCP/IP such as HTTP. The 
Web client is used to obtain information from the business server. For example, the Web client 
may send a request to the business server for an HTML document containing a product catalog. 
The business server finds the HTML catalog document and forwards the HTML catalog 
document Web client The Web client interprets the HTML catalog document to create a 
catalog display. 

FIG. lb is a simplified high level graphical representation of an exemplary set of 
interactions between multiple business systems in an exemplary e-commerce application. 
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In FIG. 1 b, a user's computer 1 a is connected via communications lines 2a and 2b to the 
Internet 3. The user's computer is equipped with memory lb, a keyboard for user input If, a 
display monitor Id and other user input devices such as a track bail le. Web browser software 
Ic is installed in the memory lb of the user's computer la. 

As the user issues conunands, the Web browser software Ic responds by sending 
instructions to and receiving instructions from the Internet 3 and each Web site 4 to vAdch the 
user chooses to communicate. 

The user accesses a particular Web site 4 using the Web browser Ic. Interacting witfi 
the Web browser 1 c, the user accesses a particular features on a particular Web page of the Web 
site 4 v4iich in this case provides die user with an opportunity to interact with data contained 
in a data base 1 1 that is accessible under a particular DBMS (Data Base Management System) 
through the Web server 13. 

The user may ask to view, select, adjust the content of, or otiierwise access the data 
presented on the Web page 4. The data presented on the Web page contains, for example, a 
catalog of goods with a price-list. In response to a user request to access the data base 1 1 , the 
user's Web browser Ic sends a requests to the Web site for data from the DBMS. In the 
example, the user requests pricing information about a particular item. 

The user's request to access data causes the Web page to activate an Active Server Page 
CASP") 14 resident in the Web server 13. The Active Server Page 14 creates HTML (Hyper 
Text Maikup Language) and script conmiands that instruct the Web server 1 3 for the Web site 
4 to perform certain processing, 

In the example, the Web server 13 instructs the ASP 14 to request S pricing source 
information from the data base 1 1 in response to the user's request; prepares a pricing request 
from the information obtained 5 from the data base 1 1 ; and sends 7 the pricmg request to a 
trading partner 9a for, in this example, pricing information about the particular catalog item 
chosen by the user. The server can commimicate 7 with any number of trading partners, 9a . . 
. 9n. In the example, the trading partner 9a responds 7 with the pricing information requested. 
The ASP 14 then builds HTML commands and sends 2b,2a, them to the browser Ic. The 
bro^yser Ic displays the information about the transaction with the trading partner and allows 
the user to interact with this data on the browser in order to refine the user's selections and 
pi^ent options. The user is typically unaware that the user's browser or the Web site accessed 
is interacting with anything other than tiie Web site with vAddi the user originally asked to 
communicate. In the example, once the user views the price for the item, the user chooses to 
purchase the selected item and to pay for the purchase with a credit card. A financial institution 
10a is contacted 8 by the ASP 14 to authorize 8 a credit-card transaction to pay for the catalog 
item. The user's completed order is recorded 12 in the data base 11. Each step may be 
recorded in the database. 

In the example depicted in FIG. lb, the data base 1 1 is a simple legacy data structure. 
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Implementmg the present invention in the exemplary embodiment described herein provides 
apparatus, systems and methods to convert the data in the data base 1 1 to an XML document 
vAnch is then, in turn, transfomied to a machine readable tree*based DOM. 

FIG. 3 is a sequence diagram illustrating an exemplary business transaction between a 
business server and a partner server. Customer 1305 uses Web client lOSS to send response 
document request 13 IS to business server lOlS. The body of the response document request 
contains item selection 1310 and instructions for purchase of the selected item from an online 
catalog. The requested response document is an acknowledgment of the item selection and 
purchase instructions. The business server receives the response document request and parses 
1320 out the item selection and purchase instructions from the response document request and 
creates aresponse. As part ofthe parsing step, the business server queries legacy database 1000 
(FIG. 1) for item availability and pricing and composes a response document based on 
templates stored in Internet database 1010 (FIG. 1). The business server sends response 
document 1 3 1 0 to the Web client and the Web client interprets 1 335 the response document to 
create a display. 

The business server notifies a business partner that a purchase order has been processed 
for the selected item. The business server sends email message 1355 to email server 1045 as 
part of a business partner notification process. Business partner 1300 uses email client 1060 
to make enudl selection 1360 that is sent as email request 1370 to the email server. The email 
server sends the email message to the email client and the email client displays 1365 the email 
message to the business partner. 

The business server orders new items from partner server 1030. To do so, the business 
server sends order document 1 325 to the partner server. The partner server processes 1 340 the 
order document and sends acknowledgment 1 345 to the business server. The business server 
uses data contained m the acknowledgment to update 1350 the legacy database. 

The business server translates data between legacy data systems and between disparate 
Intemet data systems. FIG. 4 depicts data flow within two classes of software objects 
responsible for data translation operations within the business server. Adapter software object 
1525 converts legacy data 1500 read from legacy database 1000 into XML document 1505 
using the document description found in DTD 1510 for Ae XML document The XML 
document is sent to other server objects 1515 for further processing. The adapter convc^ 
Intemet documents into a format useful for updating the legacy database. The adapter object 
receives the XML document from another server object and converts the XML document into 
legacy data for storage in the legacy database. Alternatively, the adapter may create a DTD for 
the converted XML document vAicn metadata is available for creation of the DTD. The adapter 
reads metadata 1520 and creates DTD 1510. The ad^ter uses the DTD to create the XML 
document from the legacy data read from the legacy database. Thus, the adapter uses the 
metadata to direct and control the translation of data between the legacy database and XML 
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document data structures. 

Translator object 1 700 translates one XML document into another XML docimient The 
translator receives external XML document 1710 from external object 1705. The XML 
document may need to be translated into internal XML document 1715 before it is passed to 
other server objects 1515. The translation from an external XML format to an internal XML 
format allows a single set of internal server objects to process a wide array of external XML 
documents regardless of their format or source. The single set of internal server objects need 
only know how to manipulate a set of internal XML documents so long as each type of external 
XML document format is translatable into one of the known mtemal XML document formats. 

Translation may be accomplished if a translation document in the form of an Extensible 
Style Language Transformation (XSLT) document exists for each translation. An XSLT 
document specifies how one XML document may be translated into another XML document 
The translator reads in the external XML document and translates it using XSLT document 
document 1725 into the internal XML document The internal XML document is then sent on 
to other server objects for use within the business server. The translator may also handle 
translations from internal XML documents into external XML documents in an analogous 
manner. The translator reads an internal XML document and uses a XSLT document document 
to translate the internal XML document into an external XML docummt 

FIG 5. is a depiction of a DOM object software object The purpose of DOM object 
1800 is to encapsulate a DOM representation of a XML document and expose a plurality of 
methods useful for manipulation of the DOM and consequently the XML document represented 
by the DOM. The DOM is contained within an internal data structure 1 805. The internal data 
structure reflects the tree structure of the DOM and is in a suitable form y/hcrc nodes and leaf 
elements may be added and deleted. The internal data structure is known as an infoset and 
embodies characteristics defined by the W3C Infoset working group. This information may be 
viewed at: http:/Avww. w3.org/TR/xml-infoset. A plurality of methods for operation on the 
infoset are exposed for use by other software objects. Exemplary read 1810 method provides 
a way to populate the infoset by reading an XML document from a datastore. Exemplary add 
method 1815 provides a way to add new elements to the infoset Exemplary delete method 
1820 provides a way to delete elements from the infoset Other software objects may invoke 
and modify a DOM object as a way of reading and modifying a XML document without 
knowing how each desired operation is actually performed on the XML document 

The adapts, translator, and DOM software object will be described in greater detail later 
within this specification, they are introduced here to facilitate discussion of the business server. 

FIG. 6a is class diagram of a business server according to the present invention. The 
main control module in the business server is pipeline control module 1215, so named because 
document processing within the business server proceeds in a sequential manner through a 
collection of independent data flow paths termed pipelines. The pipeline control module is a 
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composite object composed of sorter class 1230, dispatcher class 123S, translator class 1240, 
and sender class 1245. The sorter class analyzes incoming documents to determine which 
pipeline should be used to process a particular document The sorter class may use the 
translator class to create internal working documents, herein termed doclets, for use within the 
business server. The names and locations of the internal doclets are stored in dictionary 1220 
used by all of the classes composing the pipeline control module. The dispatcher class uses 
doclets to create other doclets as the result of the application of business metfiods to the doclets. 
The business methods are encoded as business rules using a variety of programming languages 
such as Visual Basic (VB) and a variety of mark up languages such as XML. The dispatcher 
uses the translator class to create outgoing documents in a form suitable to the format of the 
incoming document. For example, if the incoming document was contained within a HTTP 
request from a client, the format for the appropriate outgoing document is a transmission 
document written in HTML that is transmitted back to the requesting client as a response. The 
outgoing documents are sent by sender class 1 245 out to the Internet. The sender class contains 
methods suitable for a pliirality of conununications protocols. For example, the sender contains 
methods enabling the sender to format and send an outgoing document as an email message 
using SMTP as the commimications protocol and the same sender contains methods to send an 
outgoing document as a HTTP response. Each of tfie classes composing the pipeline control 
module use methods in utilities class 1225 for various siq>port functions as needed. The 
pipeline control class includes Web front end class 1200 to implement communications witfi 
other software objects over the Internet Console front end class 1210 implements a user 
inter&ce for control of the operations of the pipeline control module. 

FIG. 6b is a data flow diagram illustrating intake of documents from the Web by the 
business server. Web server 1 1 10 is used as a front end to business server 1 105. The Web 
server accepts Internet documents written in several different formats. Preferably, each 
incoming document is composed at least partially in XML conforming to a DTD knovm to the 
business server such as RosettaNct docxmient 1115 and Commerce One dociunent 1120. 
Alternatively, an incoming document may be written using a custom DTD such as custom XML 
document 1 125. The Web browser passes each incoming document to the business server. 
Alternatively, the Web server may pre-process the incoming documents by invoking local 
program 1 1 00 to extract XML fragments from an incoming document and send the extracted 
XML fragments to the business server. 

The path an incoming document takes through the business server is specified by 
documents containing instructions read by the objects comprising the business server. A 
process document specifies processing steps to qpply to the incoming document and is herein 
termed a pipeline document. The instructions for matching a pipeline document with an 
incoming document are encoded in a server document 

FIG. 6c is a dataflow diagram of data through the business server. Business server 1400 
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instantiates and invokes a pipeline object 1405. The business server passes in an incoming 
document in the form of an XML document as well as request, response, and application objects 
1425 from the business server environment The pipeline creates dictionary object 1 420 for the 
storage of doclets and DOM objects. A DOM object is instantiated and invoked. Once 
invoked, the DOM object encapsulates the incoming XML document The DOM object is 
stored in the dictionary. Alternatively, sorter 1410 creates a DOM object to enc^sulate the 
incoming XML document. 

Control is passed by the pipeline to the sorter. The sorter examines the incoming XML 
document encapsulated in the DOM obj ect and determines the correct path through the business 
server business processes for the incoming XML document by matching a pipeline document 
with the incomingXMLdocument The sorter uses the process document matching instructions 
to select the correct pipeline document based on the contents of the incoming XML document 
The sorter makes a pipeline document selection and initializes the server environment as 
specified in the server document For example, the sorter loads the pipeline document into the 
dictionary and translates the incoming document into a doclet that is stored in the dictionary. 

Control passes back to the pipeline and dispatcher 1415 is invoked to processes the 
incoming XML document as defined in the pipeline document, placing any resultant processed 
documents into the dictionary. 

FIG. 6d is a data flow diagram of the operations of a sorter object according to the 
present mvention. Sorter 1610 accepts incoming XML document 1600 and creates a DOM 
object encapsulating the incoming document and stores the DOM object in dictionary 1615. 
The sorter uses a business server XML document 1620 to determine which of exemplary 
pipeline documents 1 625 and 1 630 should be used to specify the business process by which the 
incoming XML document is processed. The selected pipeline document is placed in server 
application collection 1635 for use by the previously described dispateher. 

Server documents and pipeline docimients are composed in XML. In the case of a 
procedural language such as C, a function call with a void return value takes the form of 
'fooCbarU^bar");'. The '0\ \\ and characters 

are syntactic elements that direct a compiler or interpreter to prqiare a call to the fimction 'foo* 
passing in the variable *barr and the value *bar\ In a similar maimer, tags in an XML 
document are used as syntactic elements to specify instructions for directing operations within 
a business server. For example the following XML fiagment can be used to specify a call to 
the fimction *foo': <Foo variable^'barr > bar </Fooi>. The attribute 'variable* is used to 
specify the input parameter passed as a variable and the text node *bar' is used to specify the 
parameter passed as a character string. 

Alternatively, the server and pipeline documents are preprocessed, as in an interpreted 
language such as VB Script, into bytecode, that is a highly optimized interpreted code. 
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Alternatively, the server and pipeline documents are compiled directly into machine 

code. 

FIG. 6e is an exemplary business server XML document The business server XML 
document describes the criteria used to select a XML pipeline document and translator XSLT 
document used by the sorter v/hen setting up to process an incoming XML document The 
exemplary business server XML document is composed of elements with each element defined 
by a start and end tag. The first tag 1900 identifies the document as a business server 
document Business process tag IPlOsignalsthe beginning ofadefinitionofabusinessprocess 
element containing tests and processes used to process an incoming XML document Name 
attribute 191Snamestheprocess. Pipeline attribute 1905 identifies the pipeline XML document 
to be used to process die incoming document Translator attribute 1920 identifies the XSLT 
document to be used to translate the incoming XML document In the exemplary business 
process, the process is named "ABCPurchaseOrder'' because it process a purchase order from 
ABC. The chosen pipeline is ••plABCPurchaseOrder.xml" and the XSLT document is 
"ABCPurchaseOrdcrxsl". Criteria tag 1 930 begins the definition of the criteria element by an 
incoming XML document is tested to determine if die business process should be applied to the 
incoming XML document. Test batch tag 1950 begins the description of the first test batch 
element within tiie criteria to be applied the XML document Test tag 1935 specifies the test 
In this case, the XML document must contain an XPath m tiie XML document as specified in 
path attribute value 1925. The business process defined in business process tag 1960 illustrates 
an alternative process in which object tag 1955 begins the specification of an invocation of an 
object external to tiie sorter to determine if a business process is applied to the incoming XML 
document. The object specified by text node 1945 in the example is 
"OldStyleSorter.COMObjectName". 

The XML server document comprises instructions used to Please consider that in the 
case of a function, say: 

x==foo(barl,bar2,"bar") 

When a compiler program parses tfiis, tiie 'C, V and characters are "tags" and "x", "barl", 
"bar2" and "bar" are data. In tfiis manner it is clear tiiat tiie compiler interprets tiiese as 
instructions. Our server andpipeline XML documents contain botii keywords and separator 
characters(tags), as well as variables and constants (data), but these stillconstitute "instructions" 
to our server.If we describe it in this sense, then it becomes clear that these docimientsare, 
indeed, instructions, and would in fact be preprocessed, much like aninterpreted language like 
VB Script or Java Script would be, into bytecode,or internal representation, which is a highly 
optimized interpreted code.This is what we would probably do (weVe actually talked about 
doing thisfor performance reasons), although there is no reason why we couldn'tcompile directiy 
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to machine code (except for the complexity and cost ofdoing so). 

The following psuedocode specifies how the business server document of FIG. 6e is 
parsed by sorter 1610 (FIG 6b): 

For each business process element in the server XML document: 
If there is an object element then: 

Invoke the object specified in the text node. 

Call the IsMyTypeQ method of the specified object, passing in a 
dictionary and a DOM object containing an incoming XML document 
The IsMyTypeQ method returns TRUE if the incoming XML document 
is a proper document for processing by the processes of die current 
business element 

If the return value is TRUE, then no more business elements are 
processed and the cutrent business element passes. 
If there is no object tag, then: 

Find the criteria element 

For each test batch element in the criteria element: 

For each test element in the test batch element: 

Use selectNodesQ method with the XPatfa notation to 
retrieve a node-list fiom the DOM object encapsulating 
the incoming XML document 
If the node-list is empty: 

Skip all remaining test elements in the current 
test batch element and go on to the next test 
batch element 

If all of test batch elements &il go on to the next business process. 
If all business process elements fail: 

Throw an exception because the incoming XML document is not a valid XML 

dociunent for processing by the business server. 
If a business process element passes: 

Apply the XSLT document named in the business process tag translator attribute 

to convert the incoming XML document into an internal doclet 

Store the internal doclet in the dictionary. 

If the pipeline XML document specified in the business process tag pipeline 
attribute is not cached in the application object: 

Read the pipeline XML object in and parse into a memory 

representation. 

Store the memory representation of the pipeline XML document in the 
application object 
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Store the name of the pipeline XML document stored in the application 
object in the dictionary for programmatic reference. 



Control is passed back to the pipeline object that instantiated and invoked the sorter 
object The pipeline object then instantiates and invokes a dispatcher object The dispatcher 
object modifies the doclcts created from the incoming XML document by the sorter object using 
the processes defined in the pipeline XML document read and cached by the sorter object 

FIG. 6f is an exemplaiy pipeline XML document as used by a dispatcher. A pipeline 
XML document is composed of elements herein each element is defined between start and 
end tags. Start tag 2100 indicates that this XML document is a pipeline XML document 
Exception handler tag 2107 begins the definition of an exception handler element. Handler 
attribute 2105 names the exception handler element as *'ADODB.ExceptionHandler^. The 
exception handler element specifies the processes used to compose and send an exception 
message when the dispatcher encounters an eiior. Sender tag 2010 begins the definition of a 
sender element defining the type of sender used to send an exception message. Text node 2115 
specifics that "ADODB.ExceptionSenderHTTPResponse" is the software object used to send 
an exception message as a response to a queiy. The name of the software object indicates that 
the exception message will be sent using HTTP as the communications protocol. An additional 
exception is sent via email as defined by text node 2120. 

Component tag 2136 begins the definition of a component element Tlie component 
element specifies an operation performed using the incoming XML document The pipeline 
XML document defines a series of component elements that tell the dispatcher which business 
operations to perform. The completion of all of the component elements within a pipeline XML 
document completes a transaction by the dispatcher. In the exemplary pipeline XML document, 
component tag 2136 begins the definition of a component element Type attribute 2125 
specifies the component element will be an internal database doclet Target attribute 2130 
names the internal database doclet as ''MyDoclef*. The dispatcher creates a doclet and stores 
the doclet in a dictionary as specified. The doclet is then available for use by other software 
objects through the dictionary. Text node 2135 specifies a XML document to be sent to a 
database server. The database server uses the XML document to populate the internal database 
doclet stored in the dictionary. The internal database document will contain data obtained by 
the database server from an Internet database populated with data suitable for direct conversion 
into Internet documents written in XML. Alternatively, a previously described adapter is 
invoked to populate the internal database doclet by drawing data fix>m a legacy database. 
Alternatively, the internal database doclet is encapsulated within a DOM object as previously 
described. 

Component tag 2 1 40 begins the definition of a component element defining a business 
rule. A business rule is a series of operations applied to a data set to accomplish a particular 



-18- 



wo 0W3387 PCT/CAOO/01280 

1 business transaction such as satisfaction of a purchase order. Type attribute 2 1 46 specifies thai 

the component element is a business rule. Text node 2145 specifies that the business rule is 
implemented by a software object invoked by the dispatcher. For example^ a software object 
reads data out of an internal XML document that specifies a purchase order. The software 

5 object access an inventory database and determines if there are sufficient quantities of stock to 

satisfy the purchase order. If so, the software object issues a shipping order to a shipping 
departmrat, issues a billing order to a billing department, and eannaiks the stock in the database 
for use in satisfying the purchase order. In the exemplary pipeline XML document, the software 
object implementing a business rule is ''ABCPO.MyCOMObject*'. 

1 0 The internal database doclet is transited by the dispatcher as specified in a transform 

element The dispatcher invokes a previously described translator and passes to the translator 
the name of the document to be translated and the XSLT document defining the translation. 
Component element tag 2 1 60 begms the specification of a transform element Type attribute 
2150 specifies that the component element is a transform element Source attribute 2155 

15 specifies that the internal database document named "MyDoclet" is to be translated by the 
translator. Target attribute 2 1 65 specifies that the result of the translation will be a translated 
XML document named "MyResponse". Text node 2170 specifies that the XSLT document 
used by the translator is "ABCPO.Rosettanetxsr. 

Component tag 2185 completely specifies a component element of type sender A 

20 sender element specifies how the dispatcher invokes a sender otgect used by the dispatcher to 
send the results of a business transaction back to a client that posted the incoming XML 
document Type attribute 2180 specifies that die component element is a sender element 
Protocol attribute 2 1 75 specifies the protocol to be used by the sender is for an HTTP response. 
Source attribute 2190 specifies the XML document sent by the sender is "MyResponse". 

25 FIG. 7 is a cooperation diagram depicting the operations in business server during an 

exemplary business transaction. Web client 1 700 posts an incoming document to Web server 
1710. The document is written in a markup language and contams at least one XML firagment 
specifying a business transaction. The post from the Web client specifies a Web page to be read 
bytheWebserverftomWebpagestoragel715. The Web page contains instructions to remove 

30 the XML fragment from the incornmg document to create an incoming XNfl-documOT^ The 
Web server sends the incoming XML document to business server 1 720. The business server 
invokcspipclmel725,passingintheincomingXMLdocument The pipeline creates mcoming 
DOM object 1730 encapsulating the incoming XML document The pipeline stores the 
incoming DOM object in dictionary 1 760. The pipeline instantiates and invokes sorter 1 745. 

35 The sorter reads in a busmess server XML document from server XML document storage 1 735. 
The business server XML document defines the business operations to be implemented by the 
sorter as previously described. The sorter tests the incoming DOM object as previously 
described to deterniine which business processes need to be implemented. Ifa business process 
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is identified, the sorter reads in a pipeline XML document from pipeline XML document 
storage 1740 and stores the pipeline XML document in the dictionary. The sorter invokes 
incoming translator 17SS passing in a name for a XSLT docimient The incoming translator 
reads the XSLT document from style sheet storage 17S0 and uses the XSLT document to 
translate the incoming XML document encapsulated in the incoming DOM object into an 
internal doclet processed by other objects as specified by the pipeline XML document chosen 
by the sorter. The translator stores the internal doclet in the dictionary. 

The pipeline invokes dispatcher 1770 to process the mtemal doclet created by the 
incoming translator using the business process specified by the pipeline XML document chosen 
by the sorter. The dispatcher reads the pipeline XML document and parses the pipeline XML 
document initiating the business processes specified within the pipeline XML document The 
dispatcher invokes previously described adapter 1785. The adapter uses the services of 
database server 1 790 to read data fix)m a legacy database. The ad^ter uses the data to populate 
a working doclet stored in the dictionary. The dispatcher invokes rules object 1 780 to perform 
the actual business transaction. The rules object creates working DOM object 179S 
encapsulating the woildng doclet populated by the adapter. The rules object performs any 
necessaiy operations on the working DOM object to complete the business transaction. 
Modifications to the DOM object are immediately reflected in the working doclet stored in the 
dictionary. The adapter invokes outgoing translator 1775 passing in a name for an XSLT 
document specifying the conversion of the working doclet into an outgoing XML document 
The outgoing document reads the outgoing XSLT document fipom style sheet storage 1 750 and 
creates an outgoing XML document from the working doclet The outgoing XML document 
is made available to other objects by placing the outgoing XML document in the dictionary. 
The dispatcher then invokes sender 1 776. The sender routes the outgoing XML document as 
needed thus completing the business transaction. 

Exposure of an XML Document as a Software Object 

Manipulation of a XML document's equivalent DOM structure is facilitated in an object 
oriented environment if the DOM structure is an object with e3q)osed inter&ces instead of a 
static data structure. The present invention provides a &cility for turning a DOM representation 
of a XML document into a software object, known as a DOM Object, consisting of two 
components: the Document component and the Node component In an exemplary 
embodiment, a DOM object may be created from Microsoft XMLDOM XML documents. The 
XMLDOM control from Microsoft consists of several objects. The most commonly used are 
the IXMLDOMDocument and IXMLDOMNode objects. When an XML document is loaded, 
it is loaded into an XMLDOMDociraient object The DOM component wraps the 
XMLDOMDocument object with a document component obj ect that exposes the properties and 
methods that apply to the XMLDOMDocument that it represents. (Note that reference herein 



-20- 



wo 01/33387 PCT/CAOO/01280 

to ''methods*' that apply to XML documents means logic, program instructions and the like that 
define, interface with or provide an interface with various aspects of an XML document). 

The present invention uses metadata to direct and control the translation of data between 
legacy and Internet data structures. In one embodiment, the present invention provides a 
method for converting legacy data to an Internet data structure. The Internet data structure may 
be characterizable by a tree-based structure definition. The legacy data to be converted may be 
characterized by a particular structure and by a set of relationships. The structure and the set 
of relationships that characterize the legacy data may be described by metadata comprising a 
plurality of metadata components. 

The method to convert the legacy data to a Internet data structure comprises several 
steps. The adapter transforms the metadata into a set of DTDs and a corresponding tree-based 
structure definition. The metadata may contain the number of ^columns'* (also sometimes 
referred to heiein as ''record types") contained m ihe legacy data and may provide a description 
of the relationships between the columns and between the fields of each column. 

The tree-based structure definition may comprise a plurality of node definitions. Each 
DTD declaration may be equivalent to one of the metadata components. Each of the node 
definitions may be equivalent to one of the metadata components. 

The adapter identifies and stores each equivalent DTD declaration and the 
corresponding metadata component as conversionmap components. The adapter identifies and 
stoxes each equivalent node definition and the corresponding metadata component as a 
conversion miq[> component The adapter then aggregates the conversion map components into 
a conversion map and uses the conversion map to map the legacy data into the Internet data 
structure. 

Within this DOM component-wrapped object, the XMLDOM has, for each XML 
element or attribute, an XMLDOMNode object When a new document is created from a 
template, the document that created is an "instance" of the template or class of document being 
created. To instantiate an object, an instance is made of the object that the template describes. 
Instantiating a DOM object automatically instantiates the underlying XMLDOM object DOM 
and XMLDOM objects are classes with class definitions; the class definitions of DOM and 
XMLDOM objects function as templates. A class definition means a template that defines 
properties, metiiods, and in some cases, code procedures, that underlie an object Accordingly, 
vidien a programmer wishes to useaDOM object, the programmer must use aclass to instantiate 
the DOM object into a software object 

The DOM Object also has a Node component object that wraps the DOM component- 
wrapped object. Node component objects contain all flie properties and methods needed to work 
with a specific node. The Node component object exposes a node in the underlyingXMLDOM 
object. The DOM object treats elements and attributes in sunilar manner, to the extent possible. 
The creation of new elements and attributes are handled separately, however, to ensure that tiiey 
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are created correctly. When a reference is made to aNode component object that is an attribute, 
the default property is the text property, which is the node Value of the underlying XMLDOM 
object 

The Document component object is ^^4iat is first created when a new docimient is 
created. In an exemplary Microsoft XMLDOM embodiment of the invention, the Dociunent 
component wraps the Microsoft XMLDOM XML tree by tag name, exposing Node component 
objects at each level. Most of the work happens at the Node component level. However, Node 
components are generally always attached to a Document component, directly or indirectly. 

In an exemplary Microsoft XMLDOM embodiment of the invention described herein, 
mv.DOM and/or mvDOM represents the embodiment's DOM Object; mv.Document and/or 
mvDocument rqiresents the embodiment* s Document component object, and mv.NODE and/or 
mvNODE represents the embodiment's Node component object 

FIG. 8 is a graphic representation dq;>icting the structural-element by structural-element 
wrapping feature of the invention in an exemplary Microsoft XMLDOM embodiment of the 
invention. As depicted in FIG. 8, a mvDocument 1 20 contains wiUiin it a XMLDOMDocument 
121. The mvDocument 120 points to its highest level mvNode 122; the XMLDOMDocument 
121 points to its highest level XMLDOMNode 123; tiie highest level mvNodc 122 contams 
within it the highest level XMLDOMNode 123. The highest level mvNode 122 in tfic 
mvDocument 120 structure pointsto subordinate level mvNodes 124and 126 respectively. The 
highest level XMLDOMNode 123 in die XMLDOMDocument 121 structure points to 
subordinate level XMLDOMNodes 12S and 127 respectively. The subordinate level 
XMLDOMNodes 125 and 127 are contained within the subordinate level mvNoes 124 and 126 
respectively. As depicted in FIG. 8, the invention imposes on the mvDOM the structural 
features and characteristics of the underlying XMLDOM. 

The syntax in an exemplary Microsoft XMLDOM embodiment of the invention for 
instantiating a Document component Object is as follows: 

set obj=Server.CreateObject("GAX.mvDOM") 
In the above CreateObject example, GAX.mvDOM is die ID of the class and obj is an instance 
of this class. 

In an exemplary Microsoft XMLDOM embodiment of the invention, using the 
Docimient component object, the invention provides for the loading of an XML document fiom 
an existing Microsoft DCMLDOMDocument object, a URL, or an XML string; creating new 
root nodes; appending records with assigned attributes to efficiendy link multiple related tasks; 
and validating the DOM object against its corresponding DTD or schema. 

In an exemplary Microsoft XMLDOM embodiment of the invention, the Document 
component object has the following properties: 1.) A read-only property vAnch exposes the 
Microsoft XMLDOM object so the properties that are exposed can be manipulated; 2.) A read- 
only property that exposes die Microsoft IDOM ParserError object; 3.) A read-only property 
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1 thai exposes text representation ofthe XML document 

In an exemplaiy Microsoft XMLDOM embodiment of the invention, a number of 
methods are provided. Following are exemplary syntax and examples, using VBScript and/or 
JavaScript, for an exemplary embodiment of the invention providing interface and integration 

5 capabilities in an XML Internet environment/multivalue Legacy environment In the 

embodiment described, mv.DOM and/or mvDOM represents the embodiment's DOM Object; 
mv.Document and/or mvDocument represents the embodiment's Document component object, 
and mv.NODE and/or mvNODE represents the embodiment's Node component object 

In the exemplaiy XMLDOM/multivaiue embodiment, die following method syntax 

10 creates (the word create and the word instantiate are used synonymously) an mv.DOM object 
"GAX.mvDOM": 1 .) In VBScript Syntax: 

Object doc Server.CreateObjcct("GAX.mvDOM") 

and 2.) In JavaScript Syntax: 
15 Var mvDocument = new ActiveXObject("GAX.mvDOM"): 

In both examples above, the ActiveX control must have been previously registered. 

Because Microsoft XMLDOM objects are an implementation (with some extensions) 
ofthe W3C DOM API Specification, one with ordinary skill in the art will understand that the 
invention provides the fimctionality described herein, and as depicted through the fimctionality 
provided by the embodiments described herein, with respect to any and all W3C DOM API 
compliant XML Parsers. The use of Microsoft XMLDOM is illustrative and not a limitation 
ofthe invention. 

FIG. 9 provides a sunplified, high level flow diagram depicting an exemplary 
embodiment of exemplary legacy data to Internet data conversion program logic flow. As 

25 shown in FIG. 9, the first step is to determine which table is the top-level table in the result-set 
1001. The next step is to identify the niimber of columns the top-level table has 1002. The next 
step is to search the DTD to determine the number of, and to detemiine the identity of, elements 
that do not contain sub-elements or attributes and that can contain text that exist, or can exist, 
as a child element ofthe root element 1003. Next, match these lowest level elements, one for 

30 one with result-set columns from the top-level table 1004. The next step is to find the first 
child-table and count it's columns 1005. As depicted in FIG. 9, tiie next step is to find an 
element that can be repeated, which has sufficient elements or attributes to match the number 
of columns in this child table 1006. The next step is to match these repeatable elements, one 
for one, with the result-set colunms &om the child-table 1007. Next, repeat the process as 
described above for process blocks lOOS through 1007 to the Nth level 1008. Then, repeat the 

35 process as described above for process blocks 1002 through 1008 at every any level, for all 
child tables at that level 1 009. 

With regard to the logic flow described in FIG. 9, if an element contains attributes, and 
can contain text, load the element's attributes first, then the text node of die element itself. If 
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an element can be repeated, repeat it as often as allowed, then go on to the next element. E.g.: 
If there arc three (3) columns, and the DTD defines an element that can occur 0-2 times 
followed by another element, create two of the first element, put the first two columns into 
them, and then create the next element, and place the third column's output into it. 

It may be useful to view the above-described process, as depicted in FIG. 9, as a two 
part process. One part of the process is the identification of data elements at each level of the 
hierarchy of the data, and thereby, the identification of the overall hierarchical relationships of 
the data. This part of the process corresponds to the outer logic loop depicted in FIG. 9 as 
process blocks 1002 through 1 009. The hierarchy of the data is used to define an axis, such as 
an axis of a matrix, along which the identified data elements can be partitioned as individual 
nodes for a tree data structure. The axis associated with this part of the process is, for instance 
a vertical, or y, axis. 

In the case of relational database management legacy data, this data element 
identification part of the process consists of identifying child tables in the relational metadata 
on the one hand, and finding repeatable child elements in the DTD on the other hand. Child 
tables can exist within other child tables and can exist to any number of levels; multiple child 
tables can exist as siblings within the same parmt table. Accordingly, in such a scenario, the 
present invention will follow multiple tree paths to build the XML data in a manner that 
properly preserves all of the relationships of the legacy data. 

Another part of the process is the identification of data fields widiin a particular data 
element, or tree node. This part of the process corresponds to the inner logic loop depicted in 
FIG. 9as process blocks 1005 through 1008. The data fields within each particular data element 
can be used to define a second axis, such as the horizontal, or x, axis of a matrix. This part of 
the process must be performed within each table and within each repeatable child element 

In the case of relational data base legacy data, this data field identification part of the 
process identifies the nimiber of columns referenced from the relational data table and any 
tables joined with a standard inner or outer ' jom'' to that relational data table. The data field 
identification part of tiie process then matches each of the columns identified to data elements 
that are at a data*containing level of the hierarchy and that correspond to an equivalent level of 
the table or tables being expressed 

FIG. 10 is a table representation of an exemplary set of business data. The data is 
represented in a hierarchical manner. The first colunm 701 represents information concerning 
Invoice Headers. The second column 702 represents information concerning Invoice Lines. 
The third colunm 703 represents information concerning Invoice Payments. The Invoice 
Number 704 is related to each of the columns 701 , 702, and 703. There can be multiple Invoice 
Lines for each Invoice Header. There can also be multiple Invoice Payments for each Invoice 
Header. FIG. 11 is a graphical representation that depicts the relationships between each 
""colunrn** of information. 

FIG. 12 depicts an exemplary XML structure that represents the conversion of the data 
depicted in FIGS. 10 and 1 1 using the conversion method depicted in FIG. 9 and described 
above. The conversion did not result in any data loss. 

The primary embodiment described herein for converting legacy data to an Internet data 
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Structure uses as exemplary source legacy data, data stored using a simple data structure that 
provides for multivalued attributes. Examples of technologies that provide for the creation and 
maintenance of such multivalued data structures include among others PICK, ADP CORA, 
ADDS, Reality, and RealityX systems. Advanced Pick : Open Database and Operating System, 
Roger J. Bourdon, published 1996 and Pick for Prof essionals : Advanced Methods and 
Techniques. Harvey E. Rodstein, published 1990 are incorporated for all purposes herein by 
reference as if fully stated here and provide background information concerning multivalued 
data structures such as are provided in a PICK operating system. 

The primary embodiment described herein for the legacy data to Internet conversion 
uses an exemplary XML document as the Internet data structure. Designing D istributed 
A pplications W ith Xml : Asp leS Ldao and Msmq> Stephen F. Mohr. published 1999. IE5 
Dvnamic HTML Programmer's Reference . Brian Francis, et al., pubUshed 1 999, and^adUES 
Pm g^^mef^s Reference. Alex Homer, published 1999 are incorporated for all purposes herem 
by refeirace as if fully stated here and provide background information concerning XML and 
DOM. 

Conversion of Lcgacv Data into Internet Data 

In FIG. 1, legacy database 1000 may be a simple legacy data structure. The present 
invention facilitates conversion of legacy data in the legacy database to an XML document 
which is then, in tum, transformed to a machine readable tree-based DOM. 

FIG. 13 isaformatted representationofaninvoice record inanexemplary simple legacy 
data structure. Certain display characters are used herem for purposes of discussion, inclu^ 
for instance the and * characters. These characters are used to provide a visual format 
representations of the exemplary simple legacy data structure. The actual in-mcmory 
representation is, for instance, 254 on the ASCII chart for the character represented herein with 
the display character; the actual in-memory representation is, for instance, 253 on the ASCII 
chart for the character represented herein with the display character; and the actual in- 
memory representation is, for instance, 252 on the ASCII chart for the character represented 
herein with the * V' display character. 

In the example depicted in FIG. 13, the Record ID 20 is identified by the root tag name 
of "Invoice" 21 and has a unique Invoice Number "00101" 22. The first 23 data field in the 
Record is the invoice date expressed as "11246" 24 which is a relative data format (the 
particular date format represented is the relative number of days since December 31,1 967). The 
second 25 data field is customer ID "ABC* 26. The third 27 data field is a multivalued data 
field containing two different product codes "XYZ" 28 and "XXX'* 30, separated by a value 
delimiter 29. The fourth 3 1 data field is a multivalued data field containing two quantity 
values "3" 32 and "r 34 separated by a value delimiter 33. The fifth 35 data field is a 
multivalued field containing two prices (each with two implied decimal points) "1495" 36 and 
•*995" 38 separated by a value delimiter "]" 37. 

The sixth 39 data field is a multivalued, multi-subvalued data field. The first value is 
comprised of two subvalues "Black" 40 and *^20v" 42 separated by a subvalue delimiter 'V 
4 1 . The first value is separated &om the second value by a value delimiter "]" 43 . The second 
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value is comprised of three subvalues "Red" 44, "1 lOv" 46 and "Battery" 48 each separated 
fiom the other by a subvalue delimiter ^V* 45 and 47. 

The seventh 49 data field is a multivalued data field containing two related Customer 
Check Nos/^KGS" 50 and "1076" 52 separated by a value delimiter 51. 

The eighth S3 data field is a multivalued data field containing two check dates "1 1243" 
54 and ''1 1267" 56 separated by a value delimiter 55. 

The ninth 57 data field is a multivalued data field containing two customer check 
amounts "1000" 58 and "1480" 60 separated by a value delimiter 59. 

FIG. 14 is a representation of the way in which the record depicted in FIG. 1 2 is stored 
in memory. In FIG. 1 3, each data field is separated firom the subsequent data field with a field 
delimiter 100 - 108; no data field numbcis 23, 25, 27, 3 1, 35, 39, 49. 53, and 57 as shown 
in FIG. 12 are present in the stoied data. The ID 20 and Invoice 21 label tags arc not actually 
part of the stored data but are depicted for reference of the reader. 

The present invention provides apparatus, systems and methods for converting legacy 
data, such as the simple data structures exemplified in FIG. 14, to Internet data such as a tree- 
based rich data structure for which an exemplary illustration is depicted in FIGS. 15 and 16. 
FIGS. 15 and 16 represent for readability purposes only the converted record in an edited 
format. 

To convert the data, ad^ter 1 525 (FIG. 4) examines the legacy data for data that can 
be used in certain "generic" name tags, namely, "Records" as the root tag for the entire XML 
or mark up document; "Record" for the highest data hierarchy level; "Field" for the next 
subsequent data hierarchy level; "Value" for the next subsequoit level data hierarchy level; and 
"SubValue" for the next subsequent data hierarchy level. The server is fiirther programmed to 
use the notation "<tag name>" as the start-of-data tag notation; it uses the "</tag name>" as the 
end-of-data tag notation. For instance, "<Ficld>" designates the begirming of the data for a 
particular Field level; "</Field>" designates the end of the data for a particular. Field level. 

An empty tag can be annotated as follows: "<tag name>" For mstance, "<FieldA>- 
denotes a tag that has no child elements. This notation can be used, even if the element contains 
attributes. For instance "<Field xml:space="prescrve"/!>'* is a valid element that contains no 
child elements, even though it contains an attribute. 

The adapter may receive as input alternative identifications with which the adapter 
overlays the generic name tags described above. This feature provides for a resulting marked 
up electronic document and the associated tree-based structure to be characterized by tag names 
that, as specified by a programmer, describe the data in terms that describe the business 
meaning of the data. For instance, the programmer can specify that the "Record" level be 
described as "Invoice." The generic tag name embodiment is described herein, but one of 
ordinary skill in the art of computer science will understand that the use of the generic tag name 
embodiment is not a limitation of the invention. 

The adapter recognizes the delimiter as maricing a separation between SubValue data 
fields within the source legacy data record. 

The adapter initializes the Intemet data documrat with a root tag which in this case is 
"<Records>", to describe the data contained within the target object The adapter then reads 
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a record from the legacy data, vMch for purposes of the example described here, is the record 
as depicted in FIG. 13. Then, for each record read, the server adds an empty tag, v*ich in this 
example, is "<Record>" 201a. The adapter then adds an ID attribute to the "<Record>" 201a 
tag. The adapter sets the ID attribute 201b equal "=" to the data content 22 of the data record 
read that precedes the first field delimiter 100. This process is fiurther ocplained below in more 
detail As depicted in FIG. 15, the resulting tag contains: " Record Il>^101">" where 
"OOlOr is the data content 22 contained in the data record read as shown in HG. 13 that 
precedes the first delimiter 100. 

In order to assign a value to the ID attribute, the adapter looks for the first field delimiter 
in the form of within the record. In the example record, the first field delimiter 100 is 
encountered by the adulter. In the embodiment described here, the adapter assumes that each 
legacy data record vnll contam a single Record ID and diat the Record ID level will be the first 
field in the record. Accordingly, the zdaptet recognizes the delimiter as marking the end 
of die Record ID level and as marking the end of each Field level vwthin the source legacy data 
record. Accordingly, when the ad^ter encounters the first delimiter in the record, the 
adapter inserts the start-of-data tag for the Record level **<Recon>'* 201a into the conversion 
record; the adapter uses the Record ID "00101" 22 fiom the legacy data record to build as an 
attribute of the "<Record>" 201a field, the ID attribute "ID="0010 1 201b and then inserts the 
ID attribute 201b into the "<Record>'' start-of-data t^ 201a. 

Next, the adapter scans the source legacy record for the next delimiter. After the first 
delimiter 100 and prior to encountering the next delimiter 101, the adi^ recognizes 
as data the data field 24. Accordingly, the adqrter inserts into the converted record the start-of- 
data tag notadon for the data hiowchy level immediately subordinate to the "<Record>" level, 
which is the "<Field>" notation 202. 

The adapter then encounters the next delimiter 101 in the source legacy record. 
Accordingly, die adaptec inserts the data 24 contained between die first delimiter 100 and 
the next "'^"delimiter 101 into the conversionrecord203,and inserts immediately afterthedata 
203 an end-of-data tag notation for the Field level of the hierarchy, "</Field>*' 204. 

The adaptor continues to scan the source legacy record for the next delimiter. After 
Ae delimiter 101 and prior to encountering the next delimiter 102, the adapter 
recognizes as data the data field 26. Accordingly, the adapter inserts into the converted record 
die stait-of-data tag notation for the data hierarchy level immediately subordinate to the 
"<Record>" level, which is the "<Ficld>" notation 205. 

Theadaptertfaenencountersdienext'*^" delimiter 102. Accordingly, die adapter inserts 
the data 26 contamed between die "'^'^ delimiter 101 and die next delimiter 102 into die 
conversion record 206, and inserts immediately after die data 206 an end-of-data tag notation 
for dw Field level of die hierarchy, "</Field>" 207. 

The adapter continues to scan the source legacy record for die next delimiter. After 
the delimiter 102 and prior to encountering die next delimiter 103, die ad^ter 
recognizes as data the data field 28. Accordingly, die adapter inserts into the converted record 
the start-of-data tag notation for the data hierarchy level inunediately subordinate to the 
"<Recoid>" level, which is tiie "<Field>*' notation 208. 
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The adapter then encounters a delimiter 29. The adapter is programmed to recognize 
the delimiter as marking a separation between Value data fields within the source legacy 
data record Accordingly, the adapter inserts into the converted record the start-of-data tag 
notation for the data hierarchy level immediately subordinate to the "<Field>" level, which is 
the "<Value>" notation 209. 

Having encountered the *T delimiter 29, the adapter inserts the data 28 contained 
between the delimiter 1 02 and the delimiter 29 into the conversion record 2 1 0; inserts 
unmediately after the data 2 1 0 an end-of-data tag notation for the Value level of the hierarchy, 
"</Value>" 211; and inserts into the converted record a second start-of-datatag notation for the 
data hierarchy level inmiediately subordinate to the "<Ficld>'' level, which is the "<Value>" 
notation 212. 

Next, the adapterencountersthe''^** delimiter 103. Accordingly, the adapter inserts the 
data 30 contained between the delimiter 29 and the "'^^^ deluniter 103 into the conversion 
record 213; inserts immediately after the data 213 an end-of-data tag notation for the Value 
level of the hierarchy, "<A^alue>" 214; and inserts into the converted record the end-of-data tag 
notation for the data hierarchy level unmediately subordinate to the "<Record>'' level, v^ch 
is the ''<Field>*' notation 215. Hie process described above is referred to herein as the 
multivalue conversion. 

As can be seen from the description of the Record, Field and Value level conversions, 
the invention provides for the creation of successively nested levels in the converted record 
corresponding to each subordinate level of the legacy data structure hierarchy. 

For explanatory purposes, the embodiment described herein uses a serial processing 
approach. Alternative embodiments of the invention make multiple scans of each record to 
establish, first, levels of data within the converted record for all of the highest levels of the 
legacy hierarchy; second, levels of data within the converted record for the second level of the 
legacy hierarchy; and so on. Such alternative embodiments insert data into the converted record 
using the same nesting structure as described above. 

In a maimer similar to the multivalue conversion described above, the adapter converts 
the legacy d m?*, begiiming with die delimiter 103, including the multivalued fields 32 and 
34 separated by the multivalue delimiter 33 to the converted data fields 216 tfurough 223. And 
similarly, the adapter converts the legacy data, bcginmng with the delimiter 104, including 
tiie multivalued fields 36 and 38 separated by the multivalue delimiter 37 to the converted data 
fields 224 through 23 1 . 

The invention is extensible to any number of levels of hierarchy. In the example 
depicted in FIG. 13, and in the embodiment described herein, the adapter converts subvalue 
levels of data as are represented in the source legacy data begiiming with the "'^^ delimiter 1 05 . 
multivalues are separated witii die delimiter "]", such as the delimiter 43; whereas multi 
subvalues are separated by the delimiter 'T, sudi as with the **\'* delimiters 41, 45, and 47. In 
subvalue conversion, the adapter recognizes the delimiter as separating subvalues within a 
value field. Accordingly, the adapter inserts into the converted record the start-of-data and end- 
of-data Value tag notations, e.g., 233 and 240 respectively, and nest within the start-of-data and 
end-of-data Value tag notations, e.g„ 233 and 240 respectively, the appropriate subvalue data. 
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1 e.g., 235 and 238 vath the appro{>riate start-of-data and end-of-data SubValue tag notations, 

. e.g., 234 and 236, and 237 and 239 respectively. 

In a manner similar to the multivalue conversion described above, the ad^ter converts 
the legacy data, beginning with the delimiter 106, including the multivalued fields SO and 
S2 separated by the multivalue delimiter S 1 to the converted data fields 253 through 260; the 
adapter converts tfie legacy data, beginning with the delimiter 107, including the 
multivalued fields 54 and 56 separated by the multivalue delimiter 55 to the converted data 
fields 261 through 268; the adapter converts the legacy data, beginning with the "'^^ delimiter 
108, including the multivalued fields 58 and 60 separated by the multivalue delimiter 59 to the 
converted data fields 269 through 276. When the adapter encounters an end of record in the 
1 0 source legacy data, the adapter inserts into the converted record an end*of-data tag notation for 
the Record level, "</Rccord>" 277. 

The Internet representation of the data, for instance as depicted in FIGS. 1 5 and 1 6, uses 
both beginning and ending delimiters in the forai of tags to designate the beginning and ending 
of a data element On the other hand, multivalued data, as depicted in FIG. 14, uses ending 
delimiters to designate the end of a data element The multivalued data delimiter positions are 
implicit metadata. Accordingly, each entire multivalued data record might need to be scanned 
m order to determine the structure of the record and of the data within the record. 

The result of the legacy data to Internet data conversion as described thus far, in the 
embodiment and the example described herein, is an XML document References herein to 
XML documents are understood to be electronic documents that contain an XML mark up 
20 schema. The XML document is not, however, in a tree-based form. Rather, an XML 
document must be translated to some tree-based form, such as a DOM. 

A DOM does not contain any of the start-of-data or end-of-data tag notations described 
above for the XML document Rather, a DOM is a tree-based rich data structure. 

In an embodiment, such as the one described herein, where the result of the legacy data 
to Internet data conversion is an XML document, a standard XML parser can be used to parse 
the data horn the XML document to a tree*based rqiresentation in memory. 

One feature of the above-described aspect of the invention is that the adapter does not 
need to know any particular information, or any naming conventions, about the legacy data in 
order to convert the legacy data to an Internet data structure. Rather, the conversion was done 
using generic naming conventions on the Internet side, and without any knowledge of the 
30 naming conventions on the legacy side. Nevertiieless, the converted XML document preserves 
all of the data and all of the relational and hierarchical relationship intelligence within the 
legacy data. As will be discussed fiirther below, other aspects of the invention methods to label 
the resultant Internet data structure with descriptive tag names. 

It should be understood that the example simple data structure multivalued legacy data 
is used herein for illustrative purposes only and is not a limitation of the invention. 

multivalue systems have an implicit metadata m that the metadata is discovered at the 
time that the data is read. Because the metadata is implicit in multivalue records, the metadata 
can change, to some extent, on a record-by-record basis, because the metadata is expressed in 
each record's structure. Furthermore, the metadata m a multivalue system may provide certam 
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pre-defined limitations. For instance, some multivalue structures may only provide three (3) 
levels of nesting (e.g., attribute, value, subvalue); some multivalue structures may provide for 
an arbitrary niunber of fields. 

In integrating legacy systems and data with Internet systems and data, many of the 
features of the present invention serve funcdons in both directions of such integration efforts. 
The following syntax and examples of detailed features of the invention are provided for 
illustration of the integration features. However, one with ordinary skill in the art of computer 
science will understand that inclusion of the description of these features at this partioilar point 
in the description of the invention is for illustrative purposes and does not limit the use of siich 
features to a particular direction in such integration efforts. 

In an exenqilaiy XMLDOM/multivalue embodiment, the following Load method syntax 
uses mvDocument to load an existing XML document fit>m an existing KMLDOM object, a 
URL, or an existing XML string: 

LoadDOM (IXMLDOM). 

Executing a method using the above exemplaiy LoadDOM method syntax creates an 
mv.DOM object fiom an existing Microsoft EXMLDOMDocument object; it does so in the 
exemplary embodiment without re-parsing. An exemplary Boolean string is returned by the 
method to show ^diether the document loaded successfully or not The method returns a value 
of true if the document loads successfully; false otherwise. The example as depicted below and 
as depicted in FIG. 17 is illustrative: 

set domObjec^erver.CreateObjectCMicrosoftXMLDOM") 

domObjectload("http://myurl.com/foo.xml'0 
set obj=Server.CreateObjectC'GAX.mvDOM") 
If Not obj.LoadDOM(domObject) Then 

msgBox Problem loading document!" 
End If 

obj.foo.Data»"Hello" 

Response. Write("<iP^"&domObjectselectSingleNode("Data''). 
value &" World!") 

As depicted in FIG. 1 7 and m the above exemplary illustration, operations on and/or 
changes to an mvDOM object actually effect the values contained in a Microsoft XMLDOM 
object underlying the mvDOM object. As depicted in FIG. 17, an empty instance, domObject 
130a. of a MicroSofl XMLDOM object. "MicrosoftXMLDOM'' 131, is created 130. The 
Microsoft XMLDOM object is then loaded 132 with an XML Document located at URL 
**http://myurLcom/foo.xml'' 133. An empty mvDOM object 134a, named *^AX.mvDOM" 
135, is then created. In creating the empty mvDOM object 134a. named "GAX.mvDOM 135, 
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the default stmcture of GAX.mvDOM is established as an instance of an DCMLDOM object. 
Next, the mvDOM object 1 36a (same as 1 34a) is loaded 1 37 using the Microsoft XMLDOM 
object, domObject 138 (same as 130a) structure as the internal structure of the mvDOM 
object The LoadDOM method replaces the mvDOM object structure with the Microsoft 
XMLDOM object structure. The LoadDOM method returns a Boolean string that is tested 136 
to determine whether the document loaded successfully or not. As depicted in FIG. 17, if the 
method returns a value of valse, then the document was not loaded successfully, and an error 
"1 39b" is reported in the message box 1 39a. A character string, with the value of "Hello" 142 
is assigned to the obj.foo.Data node of the mvDOM. Then, a message is written using as the 
message source die Microsoft XMLDOM object 143a (same as 130a) node "Data'* 143b 
concatenated with the word " World!". If executed, the sample code would write the words 
*'Hello World!" — showing that the changed value assigned to the mvNode Data in the 
mvDOM object actually effected the value of the XMLDOMNode Data value contained in the 
Microsoft XMLDOM object. 

Changes to the mvDOM object 'obj' instantly affect the contents of the DOM object 
'domObject'. This is because the loadDOM method wraps the passed-in XMLDOM object by 
reference. 

In the exemplary XMLDOM/multivalue embodiment, the following Load (URL 
String) method syntax loads the XML document specified by the URL synchronously, and 
validates it against the XML-schema or DTD referenced within the document (if any): 

Load (URL String) 

The following example is illustrative: 

boolValue = doc.loadC*e:\inyinvoices\amazon.xml") 

In the above example, a URL string, ''e:\myinvoices\amazon.xml", contains the URL to an 
XML document or an Active Server Page or Servlet that generates an XML document 
References to URL*s to, among others, an Active Server Page, or to a Servlet that generates 
an XML document, are illustrative of the types of technologies to which URL strings, as used 
in the examples described herem, refer, and are not a restriction of the invention. A Boolean 
string is returned to show if the document loaded successfully or not The following example 
is further illustrative: 

if not obj.load("http://myscrver.com/ 
myData-xml**) then 

* handle error 
end if 

In the exenqilary XMLDOM/multivalue embodiment, the following LoadXML (XML 
String) method syntax loads an XML document from a string: 

LoadXML PCML String) 
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The XML string is defined as a representation, in ASCII text, of an XML document The 
document is loaded synchronously, and is validated against the XML schema or DTD 
referenced within it (if any). If there is no referenced schema, the document must only be well- 
fonned. A Boolean string is returned to show if it succeeded in loading or not. The following 
example is illustrative: 

If Not obj.loadXML("<MVDataxRecord Id=""foo""xFieId>bar 
</Field></Record></MVData>") Then 

msgBox '^Problem loading document!" 
End If 

The following example is further illustrative: 

boolValue «= doc.loadXML("<InvoicexInvoiceNumber>123 
</InvoiceNumber></Invoice>) 

In the immediately preceding example, the document to be loaded and validated from an 
XML string is InvoiceNumber 123. 

The invention provides a Post method, an exemplary syntax of whidi is as follows. 

set newmvDomObj = obj.post( 

" htto://www-mvserver,coni/writeorder.asp" > ["userid-Jt "password"]) 

Executing a Post method as depicted above sends the XML object represented by the current 
mvDocument object to a specified URL for processing. Executing the above Post method 
returns a new mvDomDocument containing the response XML from Ae URL that was 
accessed. 

In the exemplary XMLDOM/multivalue embodiment, the following createRoot method 
syntax creates a new Root Node document element where RootName is the name of the root 
elemmt of the new document: 

obj.createRoot("mvData") 

Executing the above method returns the mvNode of the new object or document. Returning 
as a return value the object upon which the activity opmted, in this case, the mvNode named 
"mvData" makes the mvNode "mvData" available to the next activity. This feature of the 
invention provides the further functionality of being able to link multiple activities together 
in a single line of progranmiing code. A •^dot" notation syntax is used in an exemplary 
embodiment to link multiple activities together in a single line of code. The following 
example is illustrative: 
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obj.cteateRoot CmvData'Oappend ("Record")- 
appendAttribute CM) = 1 

In the above example of the createRoot method, a new root node <MVData>, is created, a 
<Recon]> child node is appended, an attribute called "Id" is added to the Record node, and 
a value of " 1 " is assigned to the Id attribute. 

The XML data for the above example is as follows: 



<MVdata> 

<RecordId="l"/> 
<yMVData> 



As compared to the single line of code using the above-depicted exemplary createRoot 
method syntax as provided by the invention, the equivalent code witti Microsoft's 
XMLDOM requires the several lines of code dq)icted below: 



obj.loadXML("<MVData >") 

set attrNode^obixreateAttributeCId") 

attrNode.nodeValue=" 1 " 

set eltNode«obj.createElement("Record") 

eltNode.setAttributeNode(attrNode) 

obj.selectSingld^ode("MVData").appendChild(eltNode) 



In the exemplary XMLDOM/multivalue embodiment, the following method series 
syntax example, which is also depicted in FIG. 18, validates the current mv.DOM object 
against its DTD or schema. A value of true is returned if the object is validated; false if it 
fails validation, the exposed domParseError property is interrogated to determine the reason 
for validation feilure. 



s = "<!DOCTYPE MVData T 

s = s & "<!ELEMENT MVData (Record*)>'' 

s = s & '•<!ELEMENT Record (#PCDATA)>*' 

s-s&"]>" 

S-S& "<MVDattf><RecoKl/ix/MVDattf>" 
obj.loadXML(s) 
obj.MVData.q)p«id("foo") 
if obj.validateO then 
msgBox "Data is valid" 
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else 

msgBox "Data is NOT valid" 
end if 

For the above validation syntax example, and as depicted in FIG. 1 8, the DTD indicates that 
an MVData object must contain a Record element only. A record element "s" is built 1 SOa- 
1 SOe and loaded I S 1 a into the MVData object 1 S lb with a Record element 1 S 1 a- 1 . A 'foo' 
element lS2a is appended lS2bd to the Record lS2c of the object lS2d. A "Yoo" element, 
however^isnotvalidforthisDTD. Therefore, the validation method lS3aresponse returned 
is 'Yalse*\ resulting m a message that the ^'Ddta is NOT valid" 156. 

In the exemplaiy XMLDOM/mtdtivalue embodiment, the mvDocument object has a 
number of properties which can be exposed using methods as desmbed below. For 
example, the following domDocument method syntax example exposes the underlying 
Microsoft XMLDOM object, allowing use of any functionality of Microsoft XMLDOM 
object: 

set myDom'^bj .domDocument 

The domDocument property is read-only. However, any read/write properties that the 
domDocument property exposes can be set 

As another example of mvDocument properties, the following domParseEnor method 
syntax example exposes the Microsoft IDOMParseError object: 

set myParseErropH>bj .domParseEiror 

The domParseError property is read-only. The parameters of the domParseEnor method are 
explained below: 

eirorCode 

fileposline 
linepo 
reason 

srcText 
uri 

-34. 



Returns the error number or error code as a 
decimal integer. 

Returns the number of the Ime in the document 
that contains die enor. 

Returns the character position of the error within 
the line in which it occurred. 

Returns a text description of the source and 

reason for the error, and can also include the URL 

of the DTD or schema and the node within it that 

corresponds to the error. 

Returns the full text of the line that contains the 

error or an empty string if the error cannot be 

assigned to a specific Ime. 

Returns the URL of the most recent XML 
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The domparseEm)r property can also be exposed from the underlying DOM object using 
the syntax example below: 

set myParseEnor=obj.domDocumenLpar5eError 

As another example of mvDocument properties, the following *'xml'* method syntax 
example exposes a read-only text representation of the XML document: 

String mvDocument=obj.xml 

Continuing with the exemplary Microsoft XMLDOM embodiment of the invention 
which provides interface and integration capabilities in an XML Internet 
environment/multivalue Legacy environment, a number of mvNode methods are provided. 

One such method is the appendAttribute method. The 2q[)pendAttribute method creates a 
new attribute in an existing element and returns the mvNode to that element An exemplary 
syntax is as follows: 

obj.MVData.fVpendAttributeC'xml:space")="preserve*' 

As depicted in the examples below and in the before XML fragment illustrated in FIG. 
1 9 and the after XML fragment illustrated in FIG. 20, the appendAttribute example method 
depicted above creates a new attribute, *'xml:space" l60b, in the MVData element 160a and 
assigns 160c it a value of "preserve" 160d. To illustrate the efiGect of this method, the 
following XML fragment is illustrative of an existing element (the "before" XML fragment, 
as is also depicted in FIG. 19) prior to execution of the method: 

<MVData> 
<Record> 

<Field> 

I'm first! 

</Field> 

<Field> 

new data 

</Field> 
</Record> 
</MVData> 
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Once the above example appendAttribute method is executed, the same XML fragment 
appears as follows with the attribute of the MVData element 1 60a "xmlrspace" 1 60b, and in 
FIG. 20, set equal to 160c the value "preserve" 160d: 

<MVData xml:spacc="preserve"> 

<Rccord> 

<Field> 

rm first! 
</Field> 
<Field> 

new data 
</Field> 
</Record> 
</MVData> 

Another mvNode method in the exemplary Microsoft XMLDOM embodiment is the 
s^pend Element method. The append Element method creates a new element (a Child 
element)under an existing mvNode with the iiame provided in AeelemeiitName parameter 
and returns an mvNode. The following syntax example is illustrative: 

obj.MVDataJlecord.append(Tield")=-new data" 

The append Element syntax example above, as depicted m HG. 22, creates a new Field 
element 162,164 under the existing Record element 161, 165, in the existing MVData 
element 160a, 166, and inserts the new Field at the first level after the Record element 161; 
then assigns the value ''new data** 1 63 to the mvNode that the Bppmd method returned. 

Note that the exemplary embodiment described here bdiaves in a manner consistent 
with the behavior of Visual Basic. Accordingly, assigning a value to an mvNode object with 
no specification of a property to be assigned to the string, results m a defiuilt selection of the 
'text** property being assigned to the value. This is normal behavior for Visual Basic 
objects. Someone wiA ordinary skill in the art will uruierstand tfiat this behavior is specific 
to Visual Basic and not a limitation of the invention. 

To illustrate the effect of the append Element method, the following XML fragment 
is illustrative of the existing element prior to execution of the mefliod: 

<MVData> 
<RecordA> 
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Once the above example append (elementname) method is executed, the resulting XML 
representation is, as is also depicted in FIG. 21, the following: 

<MVData> 
<Record> 

<Field> 

new data 

</FieW> 
</Record> 
</MVData> 

Some mvNode methods expose certain mvNode properties, including, for exanq>le: 
coimt, domNode, name, and text 

Hie count method returns the count of ibc number of junior sibling nodes with the 
same tag name, including the referenced sibling. An example mvDom object 'obj* containing 
the following XML (^ject is illustrative of a subject of the count me&od: 

<MVData> 

<Record Id=" 1 "><Field>one</Fieldx/Record> 
<Reconi Id="2"x^'ield>two</Field></Record> 
<Reconl Id="3"><Field>three<yFieldxyRecord> 
</MVData> 

The example count methods below, each operating on the above example XML object, 
return the values indicated below: 



ob}.MVOata.Field.count (Returns the value of 3). 

obj.MVData.FieId(l).count (Retumsthe valueof 3). 

obj.MVData.Field(2).count (Returns the value of 2). 

obj.MVData.Field(3).count (Retumsthe valueof 1). 

Another mvNode method in the exemplary Microsoft XMLDOM embodiment that 
exposes an mvNode property is the domNode method. The domNode method exposes an 
inter&ce with the DCMLDOMNODE of an existing node in the underlying XMLDOM 
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object Once this IXMLDOMNODE interface is exposed, the underlying DOM object can 
be accessed. The IXMLDOMNODE inter&ce is a read-only property, but esqrases some 
read/write properties. 

Another mvNode method in the exemplary Microsoft XMLDOM embodiment that 
exposes an mvNode property is the name method, which exposes the name of an existing 
node as a string. The name property is read-only. Accordingly, the name method cannot be 
used to rename an element or attribute. 

Another mvNode method in the exemplary Microsoft XMLDOM embodiment that 
exposes an mvNode property is the text method, which e3qx)ses the text value at an existing 
node allowing the text value of the node to be reset In the exemplary microsoft XMLDOM 
embodiment, the text method assumes ttat there is only one text value in a single node. 

Using mvNode methods and syntax as was previously explained above with regard 
to the exemplary Microsoft XMLDOM/multivalue envuronment embodiment, the following 
can be determined: the total number of child elements with the same parent and the same tag 
name; and the total number of child elements, regardless of tag name. 

In the exemplary Microsoft XMLDOM/multivalue environment embodiment, a 
childNodes method is provided for getting acoUection of child elements with matching tags. 
The childNodes method renmisacoUectionof all child element nodes of the specified pa^^ 
element that have tag names that match the value of the name parameter. The parent element 
is defined by the current mvNode object If the current mvNode object is an attribute, an 
error is generated. The tag name of each child object must match ttie value of the name 
parameter in order to be included in die collection returned by the childNodes method and 
may include a namespace qualifier. An exemplary syntax of the childNodes method in the 
exemplary embodiment is: 

mvNode.obj = childNodes ([name parameter]) 

The name parameter consists of a String. Provided the name parameter String value is 
present, childNodes method returns either a list of nodes with the tag name indicated in the 
name parameter String or a NULL value if the call Ms. The following example is 
illustrative: 

For Each MVRec In obj.MVData.childNodesCRecord") 
Response.Write("<p>Next Id»- & MVRec.Id.text) 
Next 

The childNodes example above will print a list of Id's of "Record" elements in the 
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If a name parameter String is not specified, the childNodes method returns a 
collection of all child element nodes of the specified parent element If the parent element 
is an attribute, an error is reported. If the method fidls to find any child elements for the 
specified parent, a NULL value is retumed. The following example is illustrative: 

ObjectLines = docinvoicexhildNodesQ 

In this above example, no name parameter String value is present Accordingly, the 
childNodes method returns a list of all child nodes of the parent element invoice. 

In the exemplary Microsoft XMLDOM/multivalue environment embodiment, an 
insertBefore method is provided for inserting a new sibling element before the cunent 
element, with the name specified in the elementName parameter. The insertBefore method 
returns an mvNode. The following example is illustrative: 

obj.MVData.Record.Field(l).insertBefore("Field") 

«"rm first!" 

The insertBefore example above creates a new Field element, and inserts the new Field 
element before the 1st Field element; the method then assigns the value "I'm first!" to the 
new mvNode that the insertBefore method returns. The following XML fiagmmt is a 
snapshot prior to executing the above exemplary insertBefore method: 

<MVData xml:space:"preservc'> 

<Record> 

<Field> 

new data 

</Field> 

<ZRecord> 
</MVData> 

Once the above InsertBefore (elementname) example method is executed, as depicted in 
FIG. 24 new Field element 167 and 169 is added to the Record 161 and 165, vdth the value 
of "rm first!" 168, at an mvNode level subordinate to the Record element 161 and 165, at 
the same "sibling" level as the prior-existing Field element 162 and 164, but occurring 
before the prior-existing Field element 162 and 164. The resulting XML representation is 
as follows and as is also depicted in FIG. 20: 
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<MVData xml:space*"preserve"> 



<Record> 
<Field> 

I'm first 
</Field> 
<Field> 

new data 
</Field> 
</Record> 
</MVData> 

In the exemplaiy Microsoft XMLDOM/multivalue environment embodiment 
described here, a remove method is provided for removing the current node from the 
document. The remove method does not provide any return value. The followinig example 
is illustrative: 

obj.MVDataJlecord.Field(l).removeO 

This example rranove method above removes the first Field element and any and all nested 
elements and attributes firom the Record element The following XML fiagment, and as 
dqiicted in FIG. 20, is illustrative of an XML object prior to execution of the above remove 
method example: 

<MVData xml:space^''preserve"> 

<Record> 

<Field> 

I'm first! 
</Field> 
<Field> 

new data 
</F'Kld> 
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</MVData> 

Once the above remove method example is executed, the same fragment appears as is 
depicted in FIG. 22 and as follows: 

<MVData xml:space="preserve"> 

<Record> 

<FieId> 

new data 

<A?ield> 

</Record> 
</MVData> 

In the exemplary Microsoft XMLDOM/multivalue enviroimient embodiment, an 
exists method is provided for searching the current element for any immediate child element 
that has the name specified in the search criteria. The exists method returns a value of true 
if a match is found; otherwise it returns a value of false. The following example is 
illustrative: 

if not obj.MVData.exists("Record") then 
msgBox "No items in your data!** 
end if 

The above exists method example checks to see if there are any Record elements 
immediately under the MVData element The XML fragment as depicted in FIG. 20, and as 
depicted below, is illustrative of an XML object prior to the execution of the above example 
exists method: 

<MVData xml:space="preserve"> 
<Record> 
<Field> 
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I'm first! 
</Fiel(> 
<Field> 

new data 
</Field> 
</Record> 
</MVData> 

In the above XML fragment^ an element called Recoid mists. Accordingly, the if 
statement is not true and the message box message ''No items in your data!" will not be 
generated. 

Internet Data to Legacy Data Conversion and Integration 

FIO. 23 is a graphical representation of an exemplary tree-based rich data structure 
in an exemplary Intemet data structure, which, in the case depicted, is a DOM of the data 
depicted in FIGS. IS and 16. 

The present invention provides a method for converting Intemet data to a simple 
legacy data structure. The Intemet data structure may be characterized by a tree-based 
structure definitiorL The legacy data structure may be characterized by a particular structure 
and by a set of relationships. The structure and the set of relationships that characterize the 
legacy data may be described by metadata comprising a plurality of metadata components. 

The metiiod to convert the Intemet data to the legacy data structure comprises several 
steps. Adapter 1415 (FIG. 7) transforms the metadata into a set of DTD declarations and a 
corresponding receiving tree-based structure definition. The receiving tree-based structure 
definition comprises a plurality of receiving node definitions. Each DTD declaration is 
equivalent to one of the metadata components. Each of the receiving node definitions is 
equivalent to one of the metadata components. 

The adapter stores each equivalent DTD declaration and the corresponding metadata 
component as conversion map components. The adqrter stores each equivalent receiving 
node definition and the corresponding rhetadata component as a conversion map component* 
The ad^ter then aggregates the conversion map components into a conversion map. The 
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The adapter then compares the Internet data tree-based structure with the receiving 
tree-based structure. For each node in the Internet data tree-based structure, the adapter 
identifies the equivalent receiving tree-based structure node. The adapter builds a translation 
table of the equivalent Internet data tree nodes and the corre^nding receiving tree nodes. 
The adapter uses the translation table to map the Intemet data to the receiving tree-based 
structure. Then, using the conversion map, the adapter translates the data in the receiving 
tree-based structure into the legacy data structure. 

To illustrate the invention, a multivalue data structure is used as an exemplary legacy 
data structure. The way in which the exemplary embodiment of the invention converts from 
tiie tree-based DOM structure used herein to illustrate the invention, to the exemplary 
multivalued simple legacy data structure is to traverse the tree, beginning wifli the highest 
level node 600. 

In describing the Intemet data to legacy data conversion, references to the source 
Intemet data are made with reference to FIG. 23b, references to the resulting legacy data are 
made with reference to FIG. 13. It will be understood by one reasonably skilled in the art 
that the conversion firom the Intemet data structure to the legacy data structure is basically 
the reverse process of the legacy data to Intemet data conversion. Therefore, only the first 
steps of the exemplary embodiment of the Intemet data to legacy data conversion is 
described in detail below. 

The adapter asks the highest level node 600 to list all of its immediate children. In 
response, the adapter obtains a list of all of the children to the highest level node, e.g., 602 
and 603 are depicted as options, because the details for those records will not be discussed 
herein, and 601. The adapter will traverse the tree one Record node at a time. Begiiming 
in our example with Record node 60 1 , the adapter initializes a legacy data record for the data 
contamed in the Record node 601 branch; the adapter inserts the ID, "00101" attribute of the 
Record node 601 into the begmning of the new legacy data record 22, and inserts a 
delimiter after the attribute 100. 

Further traversing the tree, the adapter asks the Record level 601 of the tree to 
identify all of its children. In response, the ad^ter obtains a list of all of the children of the 
Record level 601 of the tree. In this case, the children of the Record level 601 are listed as, 
among others. Field nodes 604, 606, 608, 613, and 626. The adapter will traverse the tree 
one Field node at a time. 

Beginning with the first Field node 604 subordinate to the Record node 601, the 
adapter finds that only one data field "11246" 605 is provided by Field node 604. 
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adapter inserts the data field ""1 1246" 60S into the new legacy record 24. 

The adapter then encounters the next Field node 606 and immediately inserts a Field 
delimeter "'^^ 101. The adapter recognizes the single data element "ABC* 607. Accordingly, 
the adapter inserts the data field ''ABC" 607 into the new legacy record 26. 

The adapter provides a number of conversion and integration capabilities, including, 
among otfiers, methods that delete records fiom a file (e.g., a method named ''DeleteXML*" 
in an XML Internet environment), read records firom a file (e.g., a method named 
"ReadXML"in an XML Internet environment), and write records to a file (e.g., a method 
named "WriteXML^in an XML Internet environment). An exemplary embodiment of these 
adapter methods is provided below using, as an illustrative example, adapter methods that 
integrate data and functionality between an XML-based Intemet environment and a 
multivalue Legacy environment, using Visual Basic script 

A DeleteXML method provides the capability to delete a record from an XML file 
that is to be written to a Legacy file, which in the exemplary embodiment depicted here, is 
a multivalue file. The DeleteXML method uses the first Field element m each Record 
element as the itemid of the item to delete fit>m the file named as the method property. An 
exemplary method syntax for the DeleteXML method is: 

obj.DeleteXML fileName, xmlString 
The parameters noted in the above syntax are defined as follows: 

fileName The name of the multivalue file to yMch to write the data. 

xmlString The String containing the XML document. The syntax only 

requires that the record elraient with an id attribute be 
specified 

An example of the DeleteXML method is as follows: obj .DeleteXML 
"INVOICES","<MVData><Record Id = ""00123""/^</ MVData>" 

The above example DeleteXML method deletes the Record Id 00123 firom a file 
named the INVOICES file. According to the example, and consistent widi the multivalue 
DTD and content model, if the record does not exist, no error message is generated. 

A ReadXML method returns an XML object from a data source, which in exemplary 
embodiment depicted here, is a multivalue data source. The file name is in the method 
property. The result is retumed as XML ou^uL The Syntax for die exemplary method is: 
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xndString=obj.ReadXML(fileName[.filterText[,maxItenis]]) 

The parameters noted in the above syntax are defined as follows: 

fileName The muneoftfaemultivalue file to get the data firom. 

filterText An optional TCL method that activates a SELECT- 

LIST. If it is omitted, all items aie selected 

maxltems 

The maximum number of items to retrieve. 
An example of the ReadXML method is as follows: 

string XML = obj.ReadXML("lNVOICES","SELECT INVOICES WITH 
CUSTCODE = •'"ABC""",10) 

In the exemplary Microsoft XMLDOM/multivalue environment embodiment 
depicted here, the above ReadXML example reads a multivalue record such as the one 
dqricted below: 

>ED INVOICES 00123 

00123 

TOP 

.L22 

001 11256 
0Q2ABC 

003 X]N 

004 1]2 

005 BLACK\220V]RED 
EOI005 

In Ae exemplary Microsoft XMLDOM/multivalue envuonment embodiment 
depicted here, the above ReadXML example returns a BSTR variable which contains the 
XML representation as shown below: 

<MVData> 

<ReconlId="00123"> 
<Field>11256</Field> 
<Field>ABC</Field> 
<Field> 
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<Value>X<yValue> 

<Value>N<yVaIue> 
</F'Kld> 
<Field> 

<Value>l<A^aIue> 

<Value>2</Value> 
</Field> 
<Field> 

<Value> 

<Subvalue>BLACK</Subvalue> 

<Subvalue>220v</Subvalue> 
<A^alue> 

<Value>RED</Value> 

</Field> 

</Recoid> 
<yMVData> 

In the exemplary embodiment depicted here, the above ReadXML example reads its 
data fiom the INVOICES file after invoking a SELECT-UST with the multivalue SELECT 
method shown. This method gets all INVOICES items which CUSTCODE equal to ABC. 
Lastly, the example returns only the first 10 items that it encounters. 

A WriteXML method writes a raw XML message to a data source, which in the 
exemplary embodiment depicted here, is a multivalue data source. The XML input contains 
the XML string to write and the filename is in the method property. An exemplary 
WriteXML method syntax is: 

obj.Wti^XML fileName, xmlString 

The parameters noted in the above syntax are defined as follows: 

fileName The name of the multivalue file to which to write the 
XML data 



xmlString 

The string contain the XML document. 
An example of the ReadXML method is as follows: 
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obj.WriteXML "INVOICES",-<MVDataXReconi Id=-"00123""xField> 
1 1256</Field> . . . </MVData>" 



The WriteXML example above writes out the INVOICES item passed to it through 
the XMLString paxameter into the INVOICES file. The example string is abbreviated but 
represents the same XML Invoice 00123 record depicted above under the ReadXML method 
description. In keeping with the standards for a multivalue DTD content model in 
accordance with the exemplaiy embodiment depicted here, the Invoice item is written out 
vdiether or not it previously existed. The defiuilt action is to overwrite if necessaiy . 

The adapter provides methods for exposing various system properties, including, 
among others, a Catalog property, a Connect Timeout property, a DataSource property, and 
ExtendedProperties method for holding scripted instructions for hosted systems, a Location 
property, a Password property, a Provider property, and a UserlD property. Described below 
is an exemplary embodiment of such system property adapter methods. As above, the 
exemplary embodiment depicts, as an illustrative example, ad^^ter methods that integrate 
properties, data and functionality between' an XML-based Internet environment and a 
multivalue Legacy environment, using Visual Basic script 

The Catalog property method exposes, in the exemplary embodiment depicted here, 
the ADODB Connection Catalog property. 

The ConnectTimeout property method, in the exemplary embodiment depicted here, 
exposes the ADODB Connection ConnectTimeout property. The de&ult is 1 S seconds. The 
syntax for the exemplaiy embodiment of the method is: 

obj.ConnectTimeout^" x 

The parameters in the above ConnectTimeout property method example are defined as 
follows: 

X This indicates how long the driver will 

wait for the connection to be made 
before timing out and displaying an 
error message. The default imlue for this 
is IS (seconds) 

An example of the ConnectHmeout property method is: 

obj.ConnectTimeout='30 
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The example Connect Timeout property method above sets the ConnectTimeout value 
to 30 seconds. 

The DataSource property method, in the exemplaiy embodiment depicted here, 
exposes the ADODB.Connection DataSource property. An exemplary syntax of the 
DataSource property method is: 

host[:socket] 

The parameters in the above DataSource property method example are defined as follows: 

host The TCP/IP hostname or IP address of the 

server which contains the multivalue data 
you wish to access 

socket You can optionally add a colon *:' and a 

socket number to override the de&ult socket 
number of 23 (tchiet). This de&ults to 
localhost:23. 

An example of the DataSource property method is: 

obj.DataSource=**myserver:2023" 

The DataSource property method above sets the DataSource property to point to a system 
with hostname myserver and connect to socket 2023. 

The ExtendedProperties method, in the exemplary embodiment depicted here, is used 
to hold the script value for scripted instructions for connectii^ to, for example, Uni Verse and 
UniData systems, A script is a series of semicolon-delimited tokens used v/hen connecting 
to hosted systems. With the exception of the replacement directives, /U, /P, and /L, script 
directives must be placed at the beginning of a token. Tokens that do not specify a directive 
are sent as is. The exemplary embodiment of thie invention depicted here supports the 
following script directives: 



Directive 


Meaning 


/Ax 


Send ASCn character code x (0.^55). 


AJ . 


Replace with the value entered for User Name. 


/P 


Replace with the value entered for Password. 


/L 


Replace with the value entered for Location. 
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/MSs 


Set the match string value to s. 


fTx 


Perfonn a case insensitive match with the cur- 
rent match string. Timeout after x 
milliseconds (x cannot be negative). 



An ExtendedProperties method example is as follows: 

obj.ExtendedProperties="/MSlogin:/r4000-4iboledb startup; )LyA13/ 
MSPasswonl:/r2000;«^yA13" 

In tiie ExtendedProperties method example above, and as depicted in FIG. 24, the 
invention provides the following instructions and essential information. First, the invention 
instructs the adapter to look for the login prompt 170. Then, the invention waits up to 4 
seconds for it before proceeding 171. Next, the invention sends liboledb startup followed 
by the Location to viiich to connect and a carriage return 1 72. Then, the invention instructs 
the adapter to wait for the Password prompt 1 73 . The invention then waits up to 2 seconds 
for it before proceeding 174. The invention next sends the password (from the Password 
property) followed by a carriage return 175. 

The Location property method, in the exemplary embodiment depicted here, exposes 
the ADODB.Connection Location property. It is useful with respect to, for example, Unidala 
and Universe connections, to determine the identity of an account or directory in which to 
work. It is not typically used in situations where the user-ID implies a location. When 
connecting to, for example, UniVerse and Unidata systems, the Location property value 
retumed by the IxKation property method is denoted by the script directive /L. An example 

of tiie Location property method is: 

obj.Location»7ud33/accounts/SALES" 

The Location property method example above sets the path to the VOC of the 
account to which the system developer will be connected, ^ch in this example, is a 
Unidata structure. 

The Password property method, m the exemplaiy embodiment depicted here, exposes 
the ADODB.Connection Password property. When connectmg to, for example, UniVerse 
and Unidata systems, this value is denoted by the script directive /P. An example of the 
Password property method is: 

obj.Password=''my!ieaily!hard$to%crack@pasword'' 
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In the Password property method example above» the system sets the password 
property to a password that is, hopefully, secure. 

The Provider property method, in the exemplary embodiment depicted here, exposes 
the ADODB.Connection Provider property and defeults to "GAXOleDB.** An example of 
die Provider property method is: 

obj.Providei= "GAXOleDB" 

The Provider property method example above sets the Provider property to its default 
value. 

The Userld property method, in the exemplary embodiment depicted here, e?qx>ses the 
ADODB.Userld property. On native multivalue sfystems, such as mv.B ASE, this is the name 
of the account to which to logon. When connecting to, for example, UniVerse and Unidata 
systems, this value is denoted by the script directive AJ. An example UserlD property 
method is as follows: 

obj-Userld^^'ORDERENTRY" 

The example UserlD property method dq)icted above logs the user/developer into an 
account known as the ORDERENTRY account 

The adapter of the invention further provides methods to oeate adqiter accessible objects, 
for establishing connections with such objects through which tiie adiqiter can operate, and 
for hft n<^H» g error and failure conditions. 

For example, the following exemplary code create an illustrative object that is 
accessible by the adapVsn 

set obj=Server.CreateObject("GAX.mvAdapter") 

In order to establish an mv.BASE connection, for example, for the above-created 
object, the following example code is representative: 

set objK:reateObjectC'GAXjnvAdq)ter**) 

obj.ConnectTimeout="30" 

obj.DataSource=" 1 0.0.0.1 :2023" 

obj.Location="" 

obj.Script= ExtendedProperties 

obj.UserId="ORDERENTRY" 

obj,Password="LETMEIN" 
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In order to establish a Unidata connection, for example, for the above-created object, 
the following example code is representative: 



set obj=CreateObject("GAX.mvAdapter") 

obj.ConnectTimeout="30" 

obj.DataSourcc="10.0.0.1 :2023" 

obj.Ix)cation="/u/data/ACCOUNTING" 

ExtendedPropcrties="mAf;/A13/n;/PyA13/na.(X}T^ 

;/L;/A13" 

obj.UserId="liboledb" 
obj.Password-''holdmeback" 

In the previous examples, the adapter object is created in the first line of code; the 
ConnectTimeout, DataSource, and Location property values are specified in the second 
through fointh lines respectively; and the actual connection is established (using scripting 
directives) in line five. 

The adapter provides for error and failure handling. The adapter returns notification 
of errors, such as ODBC, OLE DB, and ADO errors, URL connectivity errors, and other 
errors, to the controlling page so Aat the source of the error can be clearly identified. From 
the error message received, the source and the layer of the qiplication in which the error 
occurred can be identified. The following example shows an illustration of simple error 
handling using VB Script: 

on error resume next: 

obj.DeleteXML "INVOICES", "<MVDataXRecord Id = 

""00123""/x/MVData>" 

IfErroOThen 

MsgBox Enr.Description, , "For some reason, miss- 
spelled words cause problems!" 

End If 

The eiTor-handling example code above provides for the reporting of an error that 
could occur when using the DeleteXML method. 

When ADO connection errors occur, the adapter sets a prop^, such as the 
Eir.Source property, to "Provider" 

Internet Data Integration 

Another aspect of the present invention provides control and integration of Internet 
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data from within any Windows Scripting Hosted language, including among others. Visual 
Basic Script (VB Script), JavaScript, and PeriScript The data resulting from the legacy data 
to Internet data conversion described above is returned to a Web client in XML form. The 
Web client can then use (through Java, VBScript, JavaScript, PeriScript, and others) this data 
to enable the user to view, select, modify, combine and extract the data, or portions of the 
data. The way in which this aspect of the invention works is explained below. 

This aspect of the invention is a language add-in which provides for easier handling 
of tree-based electronic representations of marked up documents, such as XML documents. 
The embodiment described herein for illustrative purposes uses as an example subject mark 
up document, an XML document 

In one embodiment, a standard XML parser is used to provide some of the required 
functionality. In such an embodiment, the invention exposes some of the objects of the 
underlying standard XML parser as static properties. In this way, the invention allows 
developers to access new features of new implementations of the standard XML parser, as 
the standard is changed. References in relation to this aspect of the invention to DOM calls 
refer to calls to this standard XML par^r. In this way, the invention can provide access to 
the complete set of W3C (Worid Wide Web Consortium) defined objects such as the 
Document, Element, Attribute, NodeList, NodeMap and all other objects implemented in the 
standard XML parser. 

One feature of this aspect of the invention is that it provides for '^odepath** notation 
reference to the nodes of the DOM tree representation of a particular XML document. 
Nodepath notation is a simplified notation for referring to XML nodes tiiat uses a ''dot- 
notation** format Dot-notation is a finrnat that is familiar to programmers using scripting 
languages such as Microsoft Visual Basic and other scripting languages. 

The nodepath dot-notation feature of the invention provides programers with the 
ability to reference a child node in an XML document tree using an intuitive nodepath 
description of the child. For example, an XML document called "invoice.xml" contains the 
information as depicted in FIG. 25. As shown in FIG. 25, the information is described by 
tiie highest level start-of-data tag of **<invoicO" 801. The "<invoicc>" 801 is comprised 
of "<invoiceNumber>" 802 witfi a value of "123" 803 (and an end-of-data tag 
"</invoiceNumber>" 804) and of "<drderData>" 805 with a value of the text string "1 999- 
10-27'' 806(and an cnd-of-datatag"</orderDate>'' 807). The "<rmvoic*>^ 
the end of the invoice data. For purposes of illustrating this feature of the invention, die 
executable program logic providing this feature is referred to herein as "BizDOM," Below 
is example code to invoke the executable BizDOM progiam using the VBScript scripting 
language to call the BizDOM feature. 

Object obj = Server.CreateObject("Liberty.BizDOM'') 
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FIG. 26 provides example VBScript code that follows the initial call invoking the 
BizDOM feature and which provides a nodepath reference to the orderDate text string 
" 1 999- 1 0-27" 806. The example code as depicted in FIG. 26 shows that the invoice record 
is read by identifying the document as an object with "obj" 8 1 1 followed by a period 8 1 2 
followed by the method "loadKML"* 813. The loadXML method 813 is qualified by a 
designation of the name of the file "invoice" 816 which is followed by a period 817 and the 
file type '*xml'' 818, and which is contained within matching parenthesis 814 and 820 
respectively, and fiirther contained within matching quotes 815 and 819 respectively. 

To reference the orderDate text string ''1999-10-27" 806, the VBScript code 
identifies the data as a "String" 821 and gives the data a VBScript name of "date" 822. The 
actual text 806 is referenced by following the entire path firom the highest level of 
information, "obj" 811 (followed by a period 824), to the next level of information, 
"mvoice" 8 1 6 (followed by a period 825), to the next level of information, "orderDate" 805, 
and finally to the text 827 contained at that lowest node, "1999-10-27" 806. 

The fiill reference to the text level, "obj.invoice.orderDate.text," illustrates the dot- 
notation nodepath syntax which is a feature of this aspect of the invention. 

In order to provide the features described herein, this aspect of the invention interacts 
with the scripting language used by the programmer to invoke the BizDOM feature. 
Languages, such as scripting languages, use certain control programs, such as ActiveX 
controls, to provide a means to validate method and property names called by the 
programmer concerning a particular object Such a validation means is sometimes referred 
to as a scripting language interpreter. The embodiment described herein uses, for illustrative 
purposes, ActiveX controls as the control program that provides the immediate inter&ce with 
the example scripting language. In one embodiment, the invention is programmed using 
C-H- code, and using Visual Basic to provide some aspects and features. In one embodiment, 
some aspects of the invention are implemented as an ActiveX object on top of an MS IXML 
DOM ActiveX Object; in such an implementation, many W3C DOM functions are delegated 
to the ActiveX object 

Once the scripting language interpreter knows the name is valid for the object, it then 
calls a different method to invoke tiie property or method code. In the embodiment 
described herem, these behaviors are stq)ported by implementing the ActiveX IDispatch 
interface and its GeilDsOfNames and Invoke methods. 

When the scripting language, for example. Visual Basic Script (VBScript), tries to 
interpret (or '*parse") the reference "obj.invoice.ordcrDate.text", it does so one segment at 
a time. VBScript starts with the term "obj" 81 1 and searches its symbol table. In the 
embodiment described here, the VBScript program finds the term "obj" 81 1 in its symbol 
table as an ActiveX object. After it resolves the highest level node, in this case "obj" 811, 
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the scripting language relies on the ActiveX control to determine i^ether or not the 
properties and methods the programmer is calling with the subsequent nodes are valid 

The scripting language does not internally know vAiat syntax an ActiveX control 
supports. Rather, the scripting language calls Querylnterface for the specified object in order 
to get the object's IDispatch interface. Once the scripting language has access to IDispatch, 
it calls IDispatch::GetIDsOfNamesC*invoice") to determine if the name "invoice" is a valid 
property for the object The scripting language leaves the determination to the object as to 
vidiether a particular property or method name, such as the example here, "invoice,** is 
supported as a valid property or method for the object 

At this point, it is useful to describe another feature of this aspect of Hxe invention 
which is that it provides programmers with the ability to dynamically alter the tree-based 
representation of a mariced up electronic document, such as the DOM tree for an XML 
document This feature provides, for instance, the programmer to add a new node, and then 
immediately use a nodepath reference to the new node without any intervening program 
compilation step. 

Objects have a pre-defined set of properties and methods. Without the present 
invention, if a scripting language passes a given property or method name to the object, the 
object can return a constant identifying the property/method or return a feilure condition if 
the property/method does not exist 

I f the obj ect' s GetlDsOfNames returns successfidly , dioi the scriptmg language calls 
ipispatch : : Invoke to do the woric on the property, passing the property identifier integer and 
other information. The object's Invoke method has a hard-wired case statement on the 
property identifier and branches to code to deal witti actually updatmg or retrieving the 
specified property value. 

Without the present invention, if a feilure condition is returned fix)m 
GetlDsOfNames, then the scripting language reports an error to the programmer such as 
"Invalid syntax" vAitn a property or method name has been used that is not supported by the 
pre-defined set of properties and methods for that object. 

WiA the present invention, a failure condition is not returned firom GetlDsOfNames. 
Instead, the invention builds its own vmion of the object's names table; the invention thai 
adds the string 'invoice" to the object's names table mamtained by Ae invention's program 
if that name has not been previously added; the invention then retum the a^nropriate mdex, 
forexample, l,ofthenamewithinthemvention'sname'stableforthatobject Thescripting 
language then always calls Invoke with ttie Names table mdex provided, in this case, 1 . 

The invention provides it's own "Invoke" program code that intercepts the Invoke 
method sent by the scripting language. The invention's Invoke program receives the passed 
names table index and uses the index to look up the associated string in the object's name 
table maintamed by the invention, "invoice" in this case. The invention's Invoke program 
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then uses DOM calls to look through the DOM tree for the XML document to sec if there 
is a node at this level with the specified tag, "invoice" in Ais case. If found, the updating 
or retrieving of the property value is done using DOM calls. If not found, then 
IDispatch::Invoke returns a failure condition and the scripting language will report an error 
such as ^Invalid syntax". 

By searching the DOM tree each time the scripting language wants to resolve a 
property name, the latest additions, deletions and updates to the DOM tree are always 
reflected, resulting in the behavior of an object with cfynamic properties - properties that 
appear and dis£^>pear as the programmer modifies ttie XML document tree. 

The embodiment of this aspect of the invention resolves a property path in the 
following way. After caUmgroispatch::GetrosOflSrames(**invoiw^^ 
then calls IDispatch::Invoke(l, get) to retrieve the "invoice" property, which in turn uses 
DOM calls to look through the DOM tree. 

If found, the invention constructs a node object for "invoice". The scripting language 
then repeats the process with the returned "mvoice" node object, calling Querylnterface to 
get the object's IDispatch interface. The scripting language then calls 
GetIDsOfl^ames("orderDate") which, with the invention, adds "orderDate" to the 
invention's names table if the name has not been previously added; the invention returns the 
q)propriate index, for example, 2. Then the scripting language calls IDispatch: :Invoke(2,get) 
to get the orderDate property which, with the invention, returns anotiier node obj ect, in Ais 
case, for orderDate. 

The scripting language then repeats the process for tfie last time to get the value of 
Ae "text" property. The scripting language calls Querylnterface to get the "orderDate" node 
object's IDispatch interface. The scripting language then calls GetlDsOfNamesCtext"). The 
term "text" is a pre-defined term to the invention common to all node objects. The invention 
then returns a constant, for example 99999, to the scripting language. The scripting 
language, e.g., VBScript, then calls IDispatch: :Invoke{99999,set, "1999-10-27"). The 
invention intercepts the scripting language call to Invoke. The invention's Invoke method 
recognizes that property 99999 is the "text" property. The invention's Invoke method then 
uses DOM calls to update the text for the node to "1999-10-27*. 

Usmgtheinvention,aprogrammercanalteraDOMtree by adding a new node and 
then immediately use a nodepath to reference the new node. Using the XML invoice 
document example as depicted in FIG. 25, the following line of code would cause an error 
because there is no tax node in the document: 

String tex « obj-invoice.tax 

However, using the invention, the programmer can add a new tax node by appending 
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a tax node using the code: 
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obj.invoice.appendCW). 
Once the tax node is added, the following statement is valid: 
String tax = obj .invoice.tax 

Where a tag, such as <invoiceLine>, occurs more than once, the invention uses array 
references to dififerentiate the multiply occuning tags. 

Botfi attributes and elements can be referred to using the same path syntax. In the rare 
uistance that attributes and elements can have the same name, using the collection element 
node path distinguishes a reference from an attribute node from a reference to child element 
node with the same name. For example, book.author(n) is always the element, while 
booLauthor is a search node path that initially checks to see if it is an attribute and only 
references the element if there is no author attribute. In other words, in search node paths, 
attribute nodes take precedence over element nodes. 

The invention provides the dynamic behavior as described above in a similar manner 
with regard to deletions and updates, as well as additions. 

The invention provides for the creation of a new attribute in an existing element 

CoUectionconstnicts such as ''for each*' methods are fiequentiyprovidedby script 
languages. In one embodiment, the invention exposes as a collection of nodes, groups of 
elements that are child elements to a specific element In tiiis way, the invention supports 
collection-accessing syntax such as ''for each*' methods. 

Collections are a generalized method of exposing a number of objects so that a 
software system can iteratively process each member of the collection. According to one 
authority, a collection is "[a] group of objects. An object's position in the collection can 
change whenever a change occurs in the collection. Therefore, the position of any specific 
object in the collection is unpredictable. This unpredictability distinguishes a collection 
from an array." KRcrosoft® E xcel version 5.0 Visual Basic Proerammer's Guide. 

In a Microsoft Visual Basic development environment, the systems developer must 
have a tight couplmg witii Microsoft Component Object Model (COM) technology In order 
to expose these objects, the person developing the object is required to implement a number 
of inter&ces that aie defined by Microsoft See the defmition of collections on page 65 of 
the guide. On page 66, there is a list of the properties and methods that a user must 
implement to si^port collections. The following example is illustrative: 

<MyData><X>sunflower</X><X>zinnia</X> 
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<Y>cereal</Yx/MyData> 
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In the above example, there are three child nodes under the "MyData" node. Two of them 
are called X, one is called Y, The invention provides for two mechanisms for exposing these 
child nodes as collections. One method is to find all elements with a specific name - 
childNodes("X") - which would return a collection of two nodes. Another is to expose all 
child elements at a specific level. A person with ordinary skill in the ait will understand that 
these are two of many possible criteria that could be q>plied to generate a subset Such 
nodes are then exposed through a standard Visual Basic Collections interfisice. 

In the exemplary Microsoft XMLDOM/multivalue enviioiunent embodiment, 
exposing nodes through a standard Visual Basic Collections inter&ce is accomplished by 
creating a class to which reference is made herein as "mvCollection". The mvCoUection 
class exposes a number of properties and methods concerning the referenced collections, and 
can be initialized from underlying DOM objects. 

The mvCollection properties and methods provided by the exemplary Microsoft 
XMLDOM/multivalue environment embodiment conform to the rules governing a standard 
OLEA^B collection. As such, the mvCollection class has methods and properties that have 
to be supported by the collection class according to OLE standards. For mv.DOM the 
following standard properties and methods for a collection object are siqpported: 



New Enum Returns an OLE object that suroorts 

lEnum VARIANT. This method can not be 

accessed by users. 
Item (n) Returns the indicated item in the collection, or 

VTJEMPTY if the item does not exist 
Count Returns the number of items in the collection. 

Add Adds the indicated item to the collection. 

Remove Removes the specified item from tiie 

collection. 

Collections return their count, as well as standard ActiveX enumeration. As a collection is 
iqxiated, new elements are immediately reflected in the count and enumeration. 

In the exemplary Microsoft XMLDOM/multivalue environment embodiment, 
collections can contain just a single element or multiple elraients. For example, 
documentauthor and document.author(l ) are both valid collections even if author is defined 
only as a single element. Similarly, the first element of a multiple-valued collection can be 
referenced as myDoc.Order.detailLine as well as myDoc.Order.detailLine(l) even if the 
collection is defined to have more than 1 element 

In the exemplary Microsoft XMLDOM/multivalue environment embodiment. Node 
Pathscan be used to refercnceacoUection of elements. ModcmcoUectionsmVBSaiptand 
JScript are one-based. That is, every element has a collection of child elements even if that 
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collection will only consist of one element The following ecample is illustrative of 
referencing a collection of elements using Node Path notation: 



collectionelementnodcpath = 

nodepathxoilectionelementname (index) 

Following is an explanation of the parameters appearing in the above collection reference 
example: 

nodepatii This identifies the patii of the parent node 

of the collection in the XML document 
tree. If the nodei^ results in an attribute 
mstead of an element, an error is thrown. 

collectionelementname This identifies the element name shared 

by a set of child nodes. 

index This is a one-based integer identifying 

particular child nodes within a collection 
on a left-to-right basis. However, 
collection elements are only treated 
logically if they are adjacent If other child 
nodes not matching the specified 
collectionelementname are interspersed, 
they may be ignored. 

In the exemplary Microsoft XMLDOM/multivaluc environment embodiment, 
performing the procedure as depicted in FIG. 27 and as described as follows retrieves a 
collection of mvNodes. First, start Visual Basic 177. Then, create a Standard EXE project 
178. Next,addabuttontotheforml79. Then, go into T'roject,RefercVces andcheckGA 
express mvDOM 1.0 Type Library 180 (Note tiiat tfie names of the files and libraries are 
exemplary for illustrative purposes and are not a limitation of the invention). Then, click 

to the didog box 181,double click tiie button, so tiie code windowforMethodl^^^^ 
is displayed 182, and enter collection retrieval code 183, such as the code depicted in FIG. 
28, in the window provided. 

In tiie above example, tiie first section of the collection retrieval code depicted in 
FIG. 28 400 - 408 creates an mvDOM object and loads it with some data as follows: 

Dim objmvd As New GAXLib.mvDOM 
objmvd.createRoot("MVData").appendC'Rccord") 
appendAttribute("Id") ="abc" 

objmvd.MVData.append("Record").appendAttributc("Id"^ = "def 

objmvdMVData.append("Record'0-appendAttribute("Id"^ 

= "ghi" 
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objmvd.MVData.append("foo") = "bar" 
The tree-view representation of this data is represented as follows: 
<MVData> 
<RecoKlId="abc"/> 
<ReconIId«"def'/> 
<Reconl Id»"ghi"A> 

<foo>bar</foo> 
<yMVData> 

The next section of the collection retrieval code depicted in FIG. 28 409 - 41 1 and as 
depicted below specifies a For-Each loop to go through all child nodes of the MVData 
element causing a display of a dialog box with the name of each child node. The Record 
would be displayed three times followed by a single display of "foo". 

For Eadi Reclton In objmvd.NfVData.diildNodesO 
MsgBox RecItem.Name, , _ 
"For Each with childNodesO" 

Next 

The next section of the collection retrieval code depicted in FIG. 28 412 - 414 and 
as depicted below uses a For-Each loop that gets all child nodes of the MVData clement that 
are called Record causing the display of a dialog box diree times, showing the name Record. 



For Each Recltem In objmvd.MVData.childNodes("Record") 
MsgBox RecItem.Name, , _ 

"For Each with chadNodes(""Record"")" 

Next 

Lastly, the next section of the coUection retrieval code depicted in FIG. 28 415 - 420 and 
s depicted below explicitly retrieves the Dim objmvCoU As New GAXUb jnvCoUection, 
ses a simple for-next loop with a count of chUdNodes to create a collection of mvNodes, 
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and then successively accesses each Item by looping through the collection of mvNodes 
using an index with the standard collection property, ''Item*'. 



Dim objmvCoU As New GAXLib.mvColIection. 
Set objmvCoU = objmvd.MVData.childNodcsO 
For i = 1 To objmvCoU.Count 
MsgBox CStr(i) & & objmvColLItem(i).Name. , _ 
"Looping through using Item(n)" 

Next 

End Sub 

liiterngt Data to Internet Data Integration 

The ''meta language*' capabilities of XML that provide for tfie explicit declaration by 
each development programmer of new DTDS has resulted in each Intemet business 
independently in many cases developing a im>prietary XML structure and associated set of 
naming conventions. In response to the diversity of formats, the present invention provides 
apparatus, systems and methods for one Intemet application to use XML documents from 
multiple enterprises. 

From the legacy data to Intemet data conversion described above, an XML object is 
available to the browser that contams the legacy data, but it is in a form that, although 
modified, is reflective of the needs of the legacy DBMS and the accessing browser. Trading 
partners have structures and naming tags proprietary to their respective enterprises, or in the 
alternative, conform to one of the many available "standard" formats promulgated by 
numerous vendors. 

The present invention provides a method, using a computer, for converting Intemet 
data from one Intemet data structure to another Intemet data structure. The method is similar 
to the method described above for converting Intemet data to a simple legacy data structure. 
The furst Intemet data stmcture is characterized by a tree-based stracture definition. The 
second Intemet data stmcture is characterized by a second tree-based structure definition. 

The method for converting Intemet data fit>m one Intemet data structure to anoth^ 
Intemet data stmcture comprises several steps. The first tree*based structure definition 
comprises a first plurality of node definitions. The second tree-based structure comprises 
a second plurality of nodes. 
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The computer compares the first Internet data tree-based structure with the second 
tiee-based structure. For each node in the first Internet data tree-based structure, the 
computer identifies the equivalent node in the second tree-based stmcture. The computer 
builds a translation table of the equivalent first Internet data tree nodes and the corresponding 
second Internet data tree nodes. The computer uses the translation table to map the first 
Internet data to the second Internet data tree-based structure. 

Once an XML document is transfomied to the desired fomiat, it is then posted to the 
appropriate trading partner's Web site. The trading partner then responds with the 
information requested and is posted to the originating Web site. The received information 
can then be converted by the originating server to a form suitable for the legacy DBMS . And 
finally, the converted information is written back to the data base. 

Lcfflicv Data Internet Portal 

FIG. 30 illustrates an exemplary embodiment of an legacy data Intemet portal 
embodiment of the present invention in which three tiers of systems inter&ce» the three tiers 
being: 1) one or more Web clients 301a-301n; 2) a Web server system 302; and 3) one or 
more Database Management System Server Systems (DBMS server) 305a - 305n. The use 
of suffixes "a" through "n" are used to depict an unlimited number of the subject element 
and are not a limitation of the invention. 

In tfiis embodiment, a standard architecture, such as the Microsoft Distributed 
interNetArchtecturc(DNA).isused. The three-tiered system architecture is illustrative and 
not a limitation of the invention. 

Continuing with the illustrative three-tior system embodiment, the client system 
301a-301n tier is the tier firom which a request originates. As depicted in FIG. 30, the client 
system tier is the top tier of the three-tier system relationship. A client is, for example, a Web 
browser application or a server-based application mimicking the behavior of a client 
application. A client may also be a page or other system component running on the Web 
server or the DBMS server. 

As depicted in FIG. 30, Web server 302 is the middle-tier system in the three-tier 
system architecture. In this embodiment, the Web server provides software that applies 
appropriate business logic for all transactions occurring on the portal. The Web server 
conununicates with one or more DBMS servers 30Sa-30SrL 

A DBMS server, e.g., 305a, is the server on which legacy data resides. In addition 
to the legacy data, each DBMS server, e.g., 305a, is also the server on which legacy software 
methods and programs reside. In this embodiment, the legacy software methods and 
programs, when executed, provide information about the particular DBMS server system 
305a-305n, or about the legacy data 306a-306n residing on the respective server. 
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References in the description of this embodiment to **the client"*, 'the Web Server" 
and/or 'the DBMS server" performing an action are understood to mean that the respective 
server, client, Web or DBMS server, is programmed to act in the manner described. 

In this embodiment, a client, e.g., 301a, originates a request for information and 
sends the request to the Web server. The Web server 302 receives the request It 
interrogates a table 303 that contains, among other things, information with which the Web 
server 302 identifies the appropriate DBMS server or Servers to which the request is 
directed. A single Client request may require that information be compiled from several 
DBMS servers. Accordingly, the Web server directs the request to each of die iq)plicable 
DBMS servers. For purposes of the present example, only a single DBMS server is 
described. 

The Web server 302 maintains a table 303 that contains, among other things, an 
idoitification of the appropriate communication information that must be used in order to 
communicate with each of the DBMS servers 305a-305n with \Adch the Web server 302may 
be called upon to communicate. For a particular request, the Web server 302 identifies the 
communication mechanism in the table 303 for each DBMS server to which it must direct 
the request or some portion th^xof The Web server 302 then formulates a command and 
directs a call to each of the appropriate DBMS servers 30Sa-305n as the case may be. The 
Web server 302 formulates the command and directs the call in such a manner that it is 
interpreted by the receiving DBMS server, e.g., 305a, as a request to execute a command or 
program on the particular DBMS server. 

When the appropriate DBMS server, e.g., 305a, receives the request to execute a 
command orprogram known to it, theDBMS server 305aexecutes the appropriate command 
or program. The DBMS server 305a prepares as ou^ut of the executed method or program 
the requested information. The DBMS server 30Sa directs die ou^ut information to the 
Web server 302 for analysis. 

The Web server 302 receives the DBMS server ou^ut The Web server maintains 
infonnation, for instance as part of table 303, instructing the Web server 302 as to the 
appropriate analysis procedure for each DBMS server 305ap305n to which the Web server 
communicates. The Web server 302 accesses the table 303 and determines the appropriate 
procedure with which to analyze the DBMS server response. The Web server 302 analyzes 
the DBMS server ou^t according to the instructions retrieved from the table 303, for 
instance, by requesting the DBMS server 305a for the appropriate metadata and/or parsing 
the implicit metadata available in the DBMS server output The metadata determined 
includes the number of columns of output to be generated and a mechanism for identifying 
and retrieving rows of data. The Web server 302 then retrieves the data. EiAertheWeb 
server 302 or the DBMS server 305a ensures that the first column of data retrieved is a 
unique identifier within the result data set In an alternative embodimmt, the Web server 
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302 looks for and detects a single, unique identifier within the result data set, for instance, 
a unique row number. 

When the Web server 302 is ready to retrieve the data, the Web server creates storage 
space for the result data set according to a tree-based Internet data structure 304, such as, for 
instance, an XML document The Web server 302 initializes the storage space with an 
empty root element named, e.g., "Records". For each record that the Web server 302 
retrieves, the Web server 302 creates an empty record element as a child element of the 
Records root element. The Web server 302 then reads the unique identifier element 
described above and saves the content of the unique identifier element as the content of the 
data portion of the Intemet data structure attribute, e.g., for instance, an XML attribute, for 
the new Record element that it previously oreated. For instance, the Web server 302 would 
name the unique identifier as "ID" and set the -ID** attribute to Ae contents of the unique 
identifier element. 

For each column of the output data generated by the executed method or program, 
the Web server 302 adds a new empty "Field" element as a child element of the Record 
element The Web server 3 02 then reads the data for each column and adds the data as a new 
text node to the "Field" element that it previously added. The Intemet data structure 304, 
e.g., the XML object, is complete when the Web server has completed reading all of the 
columns for all of the rows for the output data set 

It will be understood by someone with reasonable skill in the art that the description 
above of CCTtain name tags is exemplary and not a limitation of die invention. In addition, 
Ac identification of a single "Rccoids" root element is exeiiq>lary and is not a limitation of 
the invention. To the extent that the DBMS server provides enabling metadata, the Web 
server can identify and use appropriate naming tags. 

An illustrative example is provided involving the development of a Web site vMch 
will in turn communicate with a number of DBMS servers. In the example, a web site is 
being developed which will allow an administrator to query the number of users running on 
a number of DBMS servers via a Web browser. In the example, it is desired that the system 
periodically generate statistics about the usage of the various DBMS servers by various 
users. In oiderto provide the nMudmumleverageofflielegacyprogramcodeandatthe same 
time, use the latest technology, the developers of tfiis application use an XML technology 
embodiment of the legacy data to Intemet portal. 

The particular example provided illustrates the capability of the legacy data to 
Intemet portal to expose information captured by the DBMS server that is not typically 
contained in the database stored on the DBMS server. Information about the state of the 
DBMS server machine, including such information as the number of users running on the 
DBMS server machine is not typically contained in a database. For example, in SQL Server 
6.0, there is no table or database which contains data tracking the number of users connected 
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to the SQL Server. However, executing a stored procedure, 'sp^who', on such an SQL server 
will provide a list of currently connected viscrs. 

In contrast the example SQL server described above, some multivalue systems 
provide a table which contains data that, among other things, implicifly indicates the number 
of users connected to the system. In order to interpret the implicit data, the multivalue 
DBMS vendor provides a method, 'LISTU', that applies software to provide more 
information than is available in the database tables. 

In both of the cases described above, programs or methods can be executed on the 
appropriate DBMS server to gramte the desired information which is not explicitly 
contained in the raw data in the databases provided on those servers. 

In the example case of the example multivalue DBMS server systrai, a mediod-line 
mode is provided called Terminal Control Language (TCL) fiom vAdch programs and 
methods can be executed. In the example case of the example multivalue DBMS server 
system, the 'LISTLT method is provided. FIG.31 depicts an exemplary *LISTU' methodSll 
and an exemplary *LISTU' output 312 result as displayed on an ASCII terminal. 

FIG. 32 depicts an exemplary legacy data Internet portal method using Visual Basic 
Script and XML. As depicted in FIG. 32, the language parameter is set to "VBScript" 350. 
The start 351-1 and end 351-2 XML active server page code delimiters mark the begiimmg 
and ending of a scripting fiagment comprised of a series of Visual Basic methods that 
include references to a specific implementation of an XML object. The "set obj" method 
352 instructs a Web server to use the **CreateObjecr method. The DataSource 353. Userld 
354 and Password 355 properties are set to allow die object *o6j' to connect to the appropriate 
DBMS server. The readXML method 3 56 sends the method 'LISTU to the DBMS server 
for processing. The last two metihods 356 and 357 format the resulting ASCII XML data 
with appropriate headers to be transported to the client browser and identified as being of 
type 'text/xml*. 

Note that both the fu^t character ">" 3 10 is a TCL prompt character, that 'LISTU (N* 
is the command as issued and that everything below it is the output 312 of the method. 

In the example, a browser application has been created that every 60 seconds requests 
an XML document to be generated by a Web server. The Web server thm determines Aat 
it must query several multivalue systems for the number of users connected. For each 
multivalue system that it must queiy, flie Web server does the following: 1) idodfies 
thcDBMSsen^er(themultivaluesystem)tturt it must communicate witfu2)dct 
type of cormection is being made, in this system it is an ADO connection using an OLE DB 
driver, 3) looks up the type of connection and determines that there is a mechanism to pass 
DBMS server methods to the DBMS server; and 4) formulates an appropriate method and 
sends the method in the indicated maimer to the appropriate DBMS server. 
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The DBMS server executes the method in such a manner that the output is captured 
as a variable or other parameter that is returned back to the Web server. 

The Web server determines from the information contained in its table of DBMS 
server conununications that: 1) each line of ou^ut 312-317 as depicted in FIG. 31, is 
interpreted as a single row comprising a single column of data (there are six lines of data, 
therefore there are six rows, each row comprising a single colunm of text); 2) a imique 
identifier for each row is created by inverting the row numbers, and pre-pending the 
identifier as an element to each row - in this way the last row is identified as row '1', the first 
row is identified as row '6'- this identifier then becomes a new column of data in the output 
of each row. 

FIG. 33 depicts an exemplary embodiment of an XML tree-based data structure built 
by the Web server through the Legacy data Intemet portal using the DBMS output data 
depicted in FIG. 3 1 . The Web server creates an empty "<Records>" root element 330-1 and 
330-2 as soon as it knows that it can retrieve flie result set For each row read in, the Web 
server creates an empty record child element within the records element (each empty record 
child element comprises the "<Record>" and "</Record>" start and ending tags, e.g., 33 1 -1 
and 331-2; 334-1 and 334-2). 

The Web server parses each row to detennine it's implicit metadata. It finds the 
unique identifier, in this case the first of the two columns, and reads the data in that col^^ 
This data is used to create an "Itf • attribute, e.g., 332, (id-^e") and 335 (id^'3") of type ID 
in the record element for this row. The Web server then reads in all remaining columns of 
data (in this example, there is only one remaining column of data, e.g. 337) and for each, 
creates a rield element, e.g. 336-1 and 336-2 as a child element of the Record element. The 
Web server reads the data for each column, e.g., 337 as depicted, in FIG. 3 1 , and places it as 
a text node 337 as depicted m FIG. 33, within the field element, e.g. 336-1 and 336-1 that 
was created to hold it. When all columns and rows have been read in, the XML docimient 
is complete and the result set is closed. In an alternative embodiment, the Web server may 
do additional parsing. 

Having extracted the necessary data, the Web server 302 communicates the 
information back to the client, e.g., 301a. The client, e.g., 301a, in turn perfonns 
calculations on the data that it receives and then formats the ou^ut firom all the servers that 
it has queried to the browser. 

In an alternative embodiment, a program is created on the multivalue server which 
generates additional columns of output that identify, e.g., the user id (LIBERTY, JOHN and 
TIM) for each user that was signed on to the system at the time the inquiry is made, the time 
and date at vsrhich each user first logged on, and, as appropriate, some calculations on the 
information. 
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Additional Features 

A name collision situation arises in the circumstances vilicre a static Interface 
Definition Library QDL) defines a name, and the XML object with which interfece is 
required uses the same name. The XML object could reference, for instance, the same name 
both as an attribute and as an element A collision situation also arises in the circumstances 
where Visual Basic defines a term as a keyword and enforces capitalization of that term 
whenever it is used. In summary, the sources of nanung issues are: static names (standard 
and special properties and methods), element names, attribute names, and keywords. The 
present invention provides a collision resolution* 

XML allows firee-format naming of eliements and attributes, and provides some of 
ifs own names for standard objects that can exist within a DOM object One example is the 
#text object, which is the name given to a standard text node in a DOM document XML 
does not restrict nanung b^ond a certain set of characters that cannot be used in an element 
or attribute name. 

In an object-oriented world, there are inevitably base properties and methods that an 
object exposes to allow standard operations to be performed on the object's data. These are 
referred to as static identifiers and are generally exposed in a type library (TLB) or IDL. 

The invention, as illustrated in tiie exemplary XMLDOM/multivaluc embodiment 
described furtiier below, exposes XML elements and attributes as properties. Tlie invention 
provides a progranuner collision-resistant access of attributes and elements. The invention 
prpvides, inone embodiment, for tiie use of an ActiveX control in an intuitive way by Visual 
Basic progranuners to expose the elements and attributes of an XML object as properties. 
This is accomplished in a way that is natural and mtuitive to a Visual Basic progranuner, and 
does not require such progranuners to change subtie settings in the Microsoft Visual Studio 
Integrated Development environment (IDE). The maimer in which collisions are handled in 
the exemplary XMLDOM/multivalue embodiment is summarized below. 



access to: 


Use of the following will resolve a collision 
issue: 


an element 


A collection index or element(tagName) 

For example, customer.name(l) or 
customer.element(^'name*0 accesses the first 
child element with tag name of customer. 


an attribute 


An attribute(tagName) 

For example, customer.attribute(name) 
accesses tfie attribirte of customer with tag 
name. 
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(a child element with tag - "^name" should not 
be used) 


A built-in property oi 
method 


The built-in property or method 

For example, customer Jiame accesses the name 

property (customer) of the customer 

elementthree. 

There are three special static names 'name*» 
'count', and text* which are referred to as 
"special static names"; all other names are 
referred to as "standard static names". 



In the exemplary XMLDOM/multivalue embodiment, when the mv.DOM object 
parses a name in a nodepath, the logic functions depicted in FIG. 29 are performed as 
described below: 

1 . The invention first checks a name in a nodcpath against all existing methods 
and properties 421a-421b, with exception of three properties — name, count, text. 
The properties and methods checked, other than name, count, text, are standard static 
names from the IDL. 

2. If the name is recognized as one of the existing methods (that is, one of the 
standard stadc names), it is invoked 421c. 

3. If flie name parameter/argument matches a standard static name, then the 
parameter/argument must match the method or property 42 Id, If the arguments are 
valid, the method/property is called 42 If Otiierwise, if the arguments are not valid 
according to the named method or property, an error occurs 42 le. Consider the 
following example: 

MyObj.Invoice.appendC*gfgfg*') 

The above example would correctly call an existing method. In contrast, the 
foUowuig example illustrates an incorrect q)proach that would result in an error 
condition: 

MyObj.operations.q>pend *= ''append operator". 

4. Ifthe name is not one ofthe existing names (that is, one ofthe standard static 
names), then the parser determines ^^ether there is an index422a attached to tiie 
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name. If the name has an index, then the name is assumed to be an element name of 
the underlying XML object being represented 422b. The parser assumes that it is an 
element name and the nodepath refers to the appropriately numbered element with 
the specified name. The following is illustrative of a correct example: 

MyObj.Invoice.Details.Line(7) 

In the above example, the seventh element with the name Line is retrieved. In 
contrast, the foUovang example illustrates a correct syntax that nevertheless results 
in an error because there is only one element called Invoice. 

MyObjJnvoice(2) 

5, If there is no index in the nodepath, the parser will compare the passed name 
with the predefined, existing standard properties 423a — name, count, text That is, 
in the absence of an index, the invention checks to see if the name is one of 'name', 
•count' or 'text' (one of the "special" static names). If one of the "special** static names 
is found, then the corresponding standard property will be invoked 423b. 

6. If there is no index in the nodepaA, and the string is not one of the pre- 
defined, existing names, the parser first tries to find an attribute with the specified 
name424a. The parser checks to see \^ether an attribute has been found 424b. If 
an attribute is found, it is retrieved 424c. 

7. If the attribute is not found, the parser will try to find the child element with 
this name 425a. The parser checks to see whether a child element is found 425b. If 
so, the child element is retrieved 425d. Otherwise, if neither an attribute nor an 
element are found, an error message is displayed 42Sc. 

8. If an element has an attribute and a child element -mih the same nam^ to 
specify the elonent in ibe nodepath use index or the elonent mrthod. 

The invention also provides an "alias** instruction. The following exanqple syntax 
is exmplaiy: 

aUas("Field"."field") 
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The alias instruction is provided because XML element and attribute names are case 
sensitive, and further because Visual Basic forces keywords to uppercase. Accordingly, the 
above exemplary alias instruction syntax is provided to allow us to see the string 'Field* as 
the value 'field'. Without the alias instruction, by default, the instruction "obj.field" is 
interpreted by Visual Basic as 'field' being a keyword; Visual Basic then forces the word 
''field" to be expressed in the coital case as "Field". The alias mediod instructs the parser 
to see Tield' and know that it must really look for and deal with an element called 'field'. 

In addition, the invention provides further instructions, including 
•attributeNameC'xxxx")' and 'elemeniName("xxxx7. tfie attributeName and elemenfl^ame 
instructions force the parser (tfie term *^parser" is used herein to mean a program, a program 
routine, a subroutine, a computer programmed in such a way, or the like, as to accomplish 
the features described) to find an attribute or element by the q>propriate name and return if s 
Node object 

For purposes of illustrating collision handling features in the exemplary 
XMLDOM/multivalue embodiment, the following examples are provided. 

An exemplary DTD defines that the element Employee has an attribute called name 
and could contain a child element called name as well. The following example is illustrative 
of a correct line of code to return the number of siblings of the Line element which have the 
same name: 

MyObjinvoice.Details.Line.count 

The following example illustrates a correctiy coded instruction to return the number 
of siblings with tiie name Line after the 7-th element (7-th element included). 

MyObj.Invoice.Details.Line(7).count 

The following example illustrates an incorrectiy coded instruction: 

My Obj .Department.Employee(3).name.FirstName 

In the above example, the "name'' witiiout index is treated asastandani property an^ 
results. 

These following three examples are correctiy coded to each retrieve the attribute 
name of tiie third element vath the name Employee: 

MyObj.Department.Employee(3).name(l).FirstName 
MyObj .DepartmentEmployee(3).element("name"). 
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FirstName 

MyObj.DepartmentEmployee(3).attribmeC'n^ 



The invention provides a **text*' property that preserves the value of a particular 
attribute with all white spaces preserved In the exemplary XMLDOM/multivalue 
embodiment, the mvNode text property is di£ferent fiom the Microsoft IXMLDOMNode text 
property. The mvNode text property represents, for an attribute, the value of the attribute 
with all white spaces preserved; for an element, the mvNode text property represents the 
value of the first text node that is a child of the subject element The following example 
illustrates the mv.DOM syntax for accessing as a text child of a particular element: 

MyObj.Invoice.Details.[#text]Q) 

In the above example, if "j'' has a numeric value, the above example method will retrieve 
the j-th text child of the Details element. 

The invention provides for the retention of all \^te spaces. In the exemplary 
XMLDOM/multivalue embodiment, white spaces are defined as newline, tab, and space 
characters. In deslctop publishing style markup, Mliite space is viewed as extraneous. On 
the other hand, in a multivalue database environment, white ^laces are viewed as crucial to 
the integrity of the data. Unlike HTML vMch ignores white space, XML has the capability 
(through the xml: space attribute) to retain all white space. The mv.DOM text propeity 
employs the following strategies when handling v^te spaces: 

1 . ) It always keeps ^te spaces exactly as they were in the source document 
That means that all significant white spaces, spaces inside attribute values and inside 
the text content, are preserved. 

2. ) It may or may not create an extra text node for insignificant white 
spaces — the white spaces between tags. The behavior is determined by the current 
value of the xml:space attribute of the ei^losing element. 

3. ) It eliminates insignificant space if flie xml space attribute does not 
exist or its value has been set to de&ult, 

4. ) It preserves insignificant v/bite space by creating additional text nodes if its 
value is set to "preserve.*' 

The invention further provides a browser interface for managing "Q-Pointers", such 
as in a multivalue system enviroimient A Q-Pointer is a synonym reference to a file, where 
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the file being referenced can be in the same account, but under a dififerent name, or in a 
diff^ent account with either the same name or a different name. 

In order to provide a browser Q-Pointer interface, an exemplary embodiment of the 
invention uses a particular routine containing information about the machine and the account 
to which to connect for access of a particular document. The name of such a routme in an 
exemplary Internet environment is the "global.asa" routine. Most other pages use the 
global.asa routine information to access an account. 

Using the global routine allows easy customization of the Q-Pointcr interface for 
different environments. However, someone with ordinary skill in the art will understand that 
use of±c global routing is not a limitation of the invention. For example, in an alternative 
embodiment, instead of using global values obtained fiom a global routine, the Q-Pomter 
interface uses hard-coded values for the interface information. 

The first web page (defaultasp) of the mvention accesses the account identified by 
the global.asa routing, and retrieves a list of Q-Pointers with their relevant informatioiL The 
invention then presents the list of Q-Pointer as a browser readable page for display on the 
user's display monitor. In an exemplary embodiment of the browser intor&ce, as depicted 
in FIGS. 21a-21b, each Q-Pointer is displayed along with options to add new Q-Pointers or 
delete any existing ones. 

The invention uses another web page, "DeletcQPointer-asp** to delete a Q-Pointer 
from the account and rctum a browser page that indicates the status of flie requested operation 
and returns operation back to the first web page. 

The invention uses another web page, "NewQPointer.asp", to add a new Q-Pointer. 
NewQPomter.asp presents a simple HTML form through which the mvention requests and 
retrieves information for a new Q-Pointer entered by a user. The invention then submits the 
user-supplied new Q-Pointer information to anodier page, "AddQPointer.asp''. The 
AddQPointer.asp page accepts the HTML form values fi^m the previous NewQPointer.asp 
page, parses this information, and uses it to validate the creation of a new Q-Pointer that 
conforms to the user-supplied information. If the addition of tiie new Q-Pointer is validated, 
then the AddQPointer.asp page Creates the new Q-Pointer and returns a browser page which 
displays the status (success or fiulure) of the operation as well as an option to go back to the 
first page. 

As used herein, the terai "page" refers to, among other Aings, an Active Server Page, 
a servlet, ISAPI, NS API or other extension technology. Someone with ordinary skill in the 
art will understand that the specific use of Active Server Pages in die exemplary embodiment 
described here is illustrative and is not a limitation of the invention. 

As used herein, the term "Browser Page" refers to the output of the server page. The 
server page generates output v^ch is read by a browser in response to the POST or GET 
request that the browser sent to the specific server page. The browser interprets this page and 
exposes it to a user as a user-intorfece. 
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An exemplary embodiment of the Q-Pointcr browser interface logic is depicted in 
FIG. 34 and an example is provided below. In the exemplary embodiment, the Q-Pointcr 
browser interface comprises a series of sample web pages that expose an account's 
Q-Pointcrs, and provide for the addition of new Q-Pointers and/or the deletion of existing Q- 
Pointeis from an account. In die example provided below, a Q-Pointer called RHQ is added 
and deleted. The invention, in the exemphuy embodiment depicted here, provides the Visual 
Basic code described below in a way that is invisible to the user. In general, the interface 
logic as depicted in FIG. 34 is to establish a connection 430; set the connection properties 
43 1 ; get the itemid, FileName, and AccoimtName using queiy strings 432; ensure that nothing 
will be overwritten 433; and build the item 434. 

Exemplary Visual Basic code for establishing a connection and setting connection 
properties is as follows: 

set obj=Servcr.CrcateObject("GAX.mvAdapter") 
obj.DataSource=Application.Contents("OLEDBDataSource") 
obj.UserId=Application.Contents(-OLEDBUser") 
obj.Password=Application.Contents("OLEDBPassword") 

The above lines of code provide a link with which to establish a connection. The user 
clicks on die Imk to invoke the access to the server. The server is accessed through a 
mechanism called resource pooling. The exemplary embodiment of flie invention depicted 
here uses Microsoft's Distributed Intemet Architecture (DNA) to achieve high scalability. 

Once the link is open and the connection is made, an interactive list of available 
Q-Pointers 440, accounts 441, and files 442 is displayed as depicted in FIG. 35. 

Exemplary Visual Basic code for getting account, item, and file information via queiy 
strings is as follows: 

ItemId=Request.QueryString("ItemId") 
ifltemld = "-then 

•Was it a POST request? 

ItemId=Request.Form.Item("ItemId") 

end if 

ifltemld = ""then 

' Not passed in, report this fidlure 
ResponscStatus^** 
Response.Write("") 
Response.End 

end if 

FUeName«Rcquest.QueryString("FileName-) 
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ifFileName = ""then 
•Was it a POST request? 

FaeNaine-RfiquestFoiin.ItemCTiIeName") 

end if 

The lines of Visual Basic code illustrated above provide a graphic user inter&ce witfi 
which to determine the existence of a particular item, such as the RHQ item 446 as depicted 
in FIG. 36, and which exposes the account, item and file information. 

As depicted in FIG. 36, scrolling through the available item list 447a-447b, RHQ is 
an item 446 on the available item-list 447a-447b. Associated with each Q-Pointer is a graphic 
"button", e.g. 448, that, if clicked by the user, causes die deletion of Aat Q-Pomter. 

Exemplary Visual Basic code for performing the precautionary step of ensuring that 
an existing item will not be overwritten is as fblloAvs: 

FUterText="SELECT MD & Itemid & "'" 

xml=obj.ReadXML("MD",FilterText,l) 

set objQ=Server.CreateObject("") 

objQ.loadXML(xml) 

if objQ.MVData.exists("Record") then 

you cannot overwrite this item 

Response.End 

end if 

The lines of exemplary Visual Basic code illustrated above provide grapidc user 
interface features as depicted in FIG.36 and as described below for following the described 
procedure: 

1.) Click the Delete button 448 to the right of the RHQ item 446. A message 
appears reporting that it has been deleted. If an attempt is made to create a 
new Q-Pointer without deletmg another of the same name, a message appears 
indicating that it already exists. Click the back button and proceed with the 
next step. 

2.) If RHQ doesnt exist, just continue wiA the next step. 

Exemplary Visual Basic code for building a Q-Pointer is as follows: 

set objQ=Server.CreateObject("GAX.mvAdapter") 

otaQ.createRoot("MVData").append("Record"). 

appOTdAttribute("Id")=ItemId 

objQ.MVData.Record.append(Tield")="Q" 
objQ.MVData.Record.append("Field")=AccountName 
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otgQ.MVData.ReconLappendCTield")»FiIeNaiiie 
obj.WriteXML "MD",objQ.xml 

The above-illustrated lines of exemplaiy Visual Basic code provide a graphic user 
inter&ce with vibida to capture user-entered information for building a Q-Pointer. As 
depicted in FIG. 35, the user clicks a Create New Q-Pointer button 443 to create the RHQ 
item in die Master Dictionary. A dialog box as depicted in FIG. 43 will then ap^ar. The user 
then enters the {4}propriate information in the fields of the dialog box as follows: 

Enter Q-Pointer Name RHQ 461 

460: 

Enter Account Name ORDERENTRY463 

462' 

Enter File Name 464: CUSTOMERS 465 



The user then clicks on the Write This Q-Pointer button 468. A page will then qypear 
indirating that RHQ was added 466 as depicted m FIG. 38. The user then clicks the Go Back 
button 467. RHQ 446 now appears in the list of items as depicted in FIG. 36. To delete Ae 
RHQ item 446, the user clicks tiie Delete button 448 associated with the item that the user 
wishes to delete. 

The invention further provides a GetFile metfiod that exposes the ability to access 
hierarchical data as XML through a standard HTML GET or POST request In the exemplary 
XMLDOM/multivaiue embodiment described hoe, the GetFile aspect of the invention uses 
a web server's jnogramming API enviroimieiit to allow it to retrieve the body of a POST 
request, or the QueryString element of a GET request The content of these values are 
txposed either as an XML object, represented as a string, or as HTML fomi variables. These 
variables or specific tags in the XML, are extracted to provide the arguments to the methods 
exposed in the embodunent of the prior invention. Specifically, Ae FileName and FilterText 
values of the XML Pass-through mechanism are extracted and called. The resulting XML 
object is Ifaen returned as a standard ht^ response with content mime-type text^xml*. 

The foUovtnng example is provided to illustrate retrieving data from the RHQ Q- 
Pomter file created m an example above. In this example, the RHQ Q-Pomter file gets its 
data from the CUSTOMERS file on the ORDERENTRY account The logic for retrieving 
data fiom a Q-Pouiter file as depicted in FIG. 39 is summarized as follows (±c "Retrieval 
Logic"): establish a cormection 470; set the connection propoties 471; put a governor 
(maxunum limit) on die request 472; specify die file to be retrieved using query strings 473; 
specify die fype of request (POST or GET) 474; specify die filter text using an optional TCL 
statement to activate a SELECT-LIST 475; read the data 476; tell die browser it is going to 
receive XML ou^ut 477; send the data 478; and e}q)UciUy aid the ou^ut (optional) 479. 

The Visual Basic code for establishing a connection and setting connection properties 
as described in Retrieval Logic functions 470 and 471 is as follows: 
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set obj=Server.CreateObject(GAXjnvAdapter") 

Set connection ptopnties obj.DataSooice»A|)plication. 

ContentsCOLEDBDa^ouice") obj.UserI<NApplicatkm. 

Contents("OLEDBUser") 

obj J>asswoid»Ai>plication. ContentsCOLEDBPasswwd") 

The above lines of code provide a browser user intecfitte, an exemplary embodiment 
of which is depicted in FIG. 40. Using the exonplaiy browser user inter&ce depicted in FIG. 
40, the user enters a URL address for GetFile.asp and presses "Enter" on a user input device, 
such as a keyboard, to open the page. Note that the exemplary full URL depicted in FIG. 41 
is http://rhacer.libertyodbc.com/Demo/GetFile.asp?FileName=RHQ&Filter- 
Text=»SELECT%20RHQ%20'r which, because of the size limitation of the graphic user 
interface window 48 1 as depicted in FIG. 40, is not displayed completely. Note furtha that 
everything preceding the question mark C?** 483) 482 in the iiiU URL is the URL of die page 
that will serve the request; everything following the question mark ("?" 483) 484 is die 
querystring value, made up of name=value pairs, separated by ampersands ("&")• Also note 
that the value portion of the name=value pairs in the querystring is URL encoded as per the 
HTML specification for a GET mediod request 

Once the connection has been established quickly and easily using the invention, many 
of the above-described procedure steps are performed automatically. For exanq>le, the 
Retrieval Logic functions 472 - 475 described above involved in Specifying the Nature of die 
Request, require Visual Basic code such as the exemplary code ("Request Specification 
Code") depicted in FIG. 42 and as illustrated below: 

maxItems^'lOO 

FileName=RequestQueiyStringCTiIeName") 

IfFUeName = ""Then 

FileName=RequestFormJtem("FileName") 

End if 

FilterText=Request.QueiyStringCTilterText") 
ifFilterText = ""tfien 

FUterTextFRequest.Form.Item("FUterText") 

end if 

As dqiicted in FIG. 42, the first line of the Requ^ Specification code 486 sets a 
governor (a maximum) that ensures that if more tiian 100 records are requested, only the first 
100 are returned. The second dirough fourth lines of the Request Specification code 487-489 
retrieve die FileNamevariableregardlessofwhedier die FileName is provided diroughaGET 

mediod or POST mediod. The fifth through sevendi lines of die Request Specification code 
490-492 retrieve die FilterText value re^udless of v«^edier llie FilterT«ct value is provided 
dirough a GET mediod or POST mediod. 
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The lines of code illustrated in FIG. 42 and described above provide a dialog box 493 
as depicted in FIG. 43, which prompts the user specify a FileName 494 and the FilterText 
496. For example, the FileName entry 495 and the FilterText entry 497 arc made as follows: 
FUeName=RHQ 495; FiIterText=SELECT RHQ 4 497. The corresponding filter text is 
generated behind the scenes. 

Inorderto accomplish Retrieval Logic functions 476-479 for Retrieving the Data, the 
exemplary Visual Basic code depicted in FIG. 44 and as depicted below is illustrative of the 
coding required ("Retrieval Code'O: 

xml=obj.ReadXML(FileNameJ^iIterText,niaxItems) 

Re$ponse.ContentType»"text^cmi" 

Response. Write(xml) 

Response.end 

In the first line of the exemplary Retrieval Code 500 depicted in FIG. 44 and as 
illustrated above, the ReadXML method returns an XML object fiom the data source. The 
ReadXML method uses Resource Pooling to ensure tiiat the best performance and scalability 
is achieved by the product. 

In the second line of the exemplary Retrieval Code 501 depicted in FIG. 44 and as 
illustrated above, the browser is told to receive XML output In the tlurd line of ihe 
exemplary Retrieval Code 502 as depicted in nG. 44 and as iUustrated above, tte 
Tte WriteXML(xml) method specifies the XML input: the XML to write and the name of the 
multivalue file to write to. In the fourth line of the exemplary Retrieval Code 503 as depicted 
in FIG. 44 and as illustrated above, the query is completed. 

The results of the Retrieval Code depicted in FIG. 44 and as illustrated above is that 
the first record, <Record Id=" 1 "> is retrieved from the RHQ file (which gets its data fix>m the 
CUSTOMERS file on tiie ORDERENTRY account). The information for R&B Auto Repair 
is the only record that matches the FilterText criteria (this is the item-id returned by the 
SELECT statement). The information for R&B Auto Repair is tiien displayed in the browser 
485 as shown in Figure 24a. 

The invention provides a Getltem extension to the above-described GetFile feature 
of die invention. Using the Getltem feature of the invention, instead of passing a FilterText 
value for display through the browser, the Item-Id value of an item, which in the exemplary 
embodiment is a multivalue item, is retrieved. The invention converts the item-id to an 
equivalent FilterText value that then enables retrieval of that item if it exists. The following 
example is illustrative. The Getltem feature exposes a page called GetltentLasp that the 
Getltem feature reads for the following variables: 
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FileName 
Itemid 



RHQ 
1 
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The Getltem feature uses the FUeName (RHQ) and the ItemID (1) to return the item 
with item-Id 1 from the RHQ file (which gets its data from the CUSTOMERS file on the 
ORDERENTRY account). This data is returned as XML and is displayed using the user's 
browser 511 as depicted in FIG. 45. As depicted in FIG. 45, the data for Item 1 5 1 1 is 
displayed in XML format. (Note that the full URL 510 is 
ht^://rhaccr.libertyodbc.com/Demo/CjetItem.asp?FileName=RHQ&lte^^ the result is 
similar to the result of the GetFile.asp, except that the Geiltem feature builds a SELECT 
statement for the filter text). 

An XML Abstraction of Enterprise Data Sonitu^s 

The current invention provides for converting a plurality of legacy data sources to a 
uniform model of data representation by representing each legacy data source as a virtual in- 
memory tree-based data structure. The current invention provides a tool that allows the 
user to graphically explore the data sources in the user's enterprise and to build an XML 
representation of the Enterprise View of the relevant data sources. The cunrent invention 
fiirther provides a tool that allows the user to graphically explore the metadata structures 
and/or content for each particular data source relevant to the Enterprise View and to generate 
anXMLicpresentationofeachdatasource'smetadatastructure. The tool further builds W3C 
standards*based syntax for accessing content fit>m each data source, and maps the W3C 
standards-based access ^ntax to the access syntax supported and/or native to each data 
source. 

As an illustrative example, one of the data sources available to auser*s enterprise 
is a database which can be accessed usmg Microsoft's ActiveX Data Object (ADO). In this 
illustrative example, the current invention provides a tool that allows the user to graphically 
explore the ADO database as one of the data sources available to the enterprise. In this 
illustrative example, using the current mvention, the user performs a series of gr^hical 
inquiries, such as QBE's (Queiy by Example, i.e., apomt and click technology) to display and 
select the data sources available to the enterprise, the data bases referenced by each selected 
data source, the tables referenced by each database, and the rows referenced by each table. For 
each selected data source, such as the ADO database in our example, the current invention 
generates an XML representation of the view (the "view element**) of that data source and 
appends it into the enterprise view. For each metadata level selected by the user for Ae 
selected data source, the current invention generates as an XML fragment an XML 



-77- 



wo 01^3387 PCT/CAOO/01280 
iqnesentation of user selected metadata stnictures. The current invention appends the XML 
fiagment as a chUd element of the view element for Ae data source into the enterprise view. 
The current invention then generates a W3C XPath syntax necessary to access content in the 
selected database, vMch in the illustrative example is die ADO database; the current 
invention then maps the W3C XPath ^tax to AmericanNational Standards Institute (ANSI) 
Structured Query Language (SQL) Syntax. 

In one exen4>lary embodiment of the invention, tfie current invention provides an 
application that abstracts a Relational Database Management System (RDBMS) data source 
as a virtual, in-memory DOM tree. 

In the exemplary embodiment, the current invention provides an XML schema 
Builder. The XML schema builder is a program tiiat pronqits the user for a datasource 
identifier and cotain properties, connects the current invention to a specific database catalog, 
and then provides the user with the ability to iq)ply die datasource identifier, the properties, 
and the database catalog as part of an XML stracture. For example, the XML schema builder 
prompts die user for an ActiveX Data Object (ADO) datasource and properties. Once die user 
siq)plies the requested information, die XML schema builder connects die current invention 
to a specific Object Linking and Embedding (OLE) Database (DB) Catalog. The current 
invention tiien provides for die application of the ADO datasource and properties as well as 
die OLE DB Catalog to an XML structure. 

The current invention prompts die user to supply a Root Element Name for die 
XML representation. In an iUustrative example, die Root Element Name is 
"myEnterpriseView". As described below, a data model is selected to represent a data source 
as a DOM tree. In die example described below, an example template for representing data 
in multiple RDBMS data sources widiin an enterprise is provided. A person widi ordinary 
skill in die art will understand diat die examples provided illustrate an exemplary 
embodiment, and are not a limitation of the uivention. 

As previously mentioned above, a Root element can contain attributes. A Root 
element can also contain an element wid» which to specify "View" properties about the 
structure and toailedinforniationabout what can be contained in die structure. Anillusttadve 

«cample of a View Root Element is provided below. 
<SnyEnterpriseView readWrite="readonly"> 
-^;»opertieS> 

<viewTypes> 

<viewTyptf>ADO</viewTyptf> 
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<viewType>fUc:HTML</viewType> 

<viewType>http:HTML<yviewType> 

<viewType>https:HlML</viewType> 

<yvicwTypcs> 

<;/properties> 

</myEntcrpriseVicw> 

The Root Element further contains an clement called •Mews", which contains 
individual view elements with a name attribute containing the name of the view. As depicted 
in the illustrative example below, the 'view name" contains a name of a type identifier. The 
type identifier creates restrictions on die type of datasource that can be viewed. 

<myEnterpriseView readWrite«"readonly"> 

<properdes> 



</properties> 
<views> 

<viewname="mySqlServerView" typc^^ADO" providerString="...'> 
• • • 

</view> 
</views> 
</myEiiteipriseVieW> 

The providerString attribute specified above is the OLEDB Provider String ITO 
The example above demonstrates that in the exonplaiy embodimoit depicted hae, various 
properties can be specified with separate values. 

Extending the description of the illustrative example fiirther as dq>icted below, the 
XML schema builder provides the user with the ability to refisrence specific RDBMS 
elements, for example, catalogs, publishers, tables of authors and titles, and stored 
procedures. 

<QnyEnterpriseView> 
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</properties> 
<views> 

<viewname="mySqlSeiverVicw" type="ADO" pn)viderString=-. • ."> 
<catalogs> 
<pubs> 

<tables> 

<authors/> 
<litles/> 

</tables> 

<storedProcedures> 

</storedProcedures> 

</pubs> 

<catalogs> 

<Adew> 

</views> 

</myEnteipriseView> 

The current invention provides for View Definition and provides a View Definition 
Builder. A View Definition is an XML file Aat describes the <view> elements and their 
respective immediate attributes. In the exemplary embodiment, the View Definition is static 
and can be represented in memory. 

The View Definition Builder is a program that creates an empty View Definition and 
then prompts the user to create anew view. The View Definition Builds applies the resulting 
DOM tree as an ASCII XML file to die Root Element, which in the case of the illustrative 
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example is, *'xnyEnterpriseView.xinl'*. Additionally, the current invention prompts the user 
to select the view types, e.g., ADO, file: HTML, etc. The current invention further prompts 
the user to select a name for the view and to assign all relevant OLE DB properties to 
establish a coimection. 

The current invention provides a View Representation Builder. The View 
Representation Builder is a program that travels through the structure created in the XML 
schema builder and View Definition Builder functions desmbed above. As the View 
Representation Builder travels through the View structure, it creates an in-memory DOM tree 
wing the features of the invention previously described above. 

To do this, the View Representation Builder uses the view definition item to traverse 
all views and retrieve all table and column names, and in an alternative embodiment, all 
stored procedures. 

A layered dynamic XML DOM interfiu» is provided. ThcDOMmtcrfaccisusedas 
adynamic layer over other representations of DOM objects. In Ais way, the current invention 
creates the e£fect of an in-memoiy grq>h of the metadata and data objects diat comprise the 
enterprise view. This dynamic enterprise view acts in sonie respects as operating system. 

In the preferred embodiment, the current invention provides: 

Support for XPath, XLink, XSL, XSLT, XPointer and other W3C features. 

Full DOM Level 1 support (research level 2) 

Identification of a doc-fauU (page-fisiult) \^en a reference was made to 
something that was not in memory; this would trigger dynamic loading. 

Governors that prevent certain users fix)m performing certain combinations of 
functions. For instance, a restriction prevents a user fix)m applying an XSLT transformation 
against 3 200-Terabyte Oracle servers and a 3 Terabyte Sql Server database. 

Definition of nested structures (such as, for example, using shape-provider- 
generated data) as ou4)ut 

Leverage the MSXML object stnK:ture to get the latest in innovations; 
A meta-layer for some of the functionality. 

As mentioned above, the current invention provides for layered views. In the 
exemplary embodiment, the current invention provides for an Enterprise Layer, a Database 
Metadata Layer, and a Data Record Layer. 

The Enterprise Layer is the highest level layer and represents the XML View object 
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The XML View object was previously described above. 

The Database Metadata Layer represents the metadata describing the databases and 
tables and table schema of fhe data source. This layer is dynamic and provides for data 
loading on demand. The Database Metadata Layer is subordinate to the Enterprise Layer. 

The Data Record Layer is subordinate to the Database Metadata Layer. The Data 
Record Layer represents a row or rows of data from a particular database that is to be 
searched. When a user receives a result from the server, the result will indicate a rowset, 
which equates to a nodeList in DOM tmns. Li one embodiment, at this point, the current 
mvention will not provide Ac user witfi the number of nodes (rows) in the nodeList; to get 
a count, a pass through the entire result set is required. In an alternative embodiment, 
scrollable cursors on the server are used to obtun a count 

The current invention provides for interaction between the view layers. The current 
invention provides a mechanism that parses W3C standards-based syntax for accessing XML 
data and performs the following fimctions: 

Identify the depth to which traversal is being done 

At whatever deptti interaction is hiq[>pening, prevent recursion into another 
level without controlling the way in v^ch this is done. 

Apply governors to ensure diat too large a set is not invoked. 
Apply a commit mechanism to enable writing the data back. 

Apply a security mechanism that prevents creation of an object at a level to 
which the user does not have access. For example, if a user applies XPath syntax to 

the abstracted view of the enterprise, the current invention parses the XPath syntax to 
determine which portions of it reference the enterprise level definition and which portions of 
it reference the data source level The current invention maps the XPath syntax into a Query 
execution plan that mcludes steps such as traversing the enterprise level XML, opening 
connections to data sources, creating data source-specific syntax for accessing data, and 
building the appropriate output structures. 

In the exemplary embodiment, the current invention provides an XML syntax that 
defines a shape-provided nested table join function. In the exemplary embodiment, this 
feature uses the ADO Shape Provider. 

In an alternative embodiment, the current invention pro^ddes a syntax that builds an 
in-memory tree ofdata, then performs a conmiit The commit mvokes a two-phase commit 
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against the baclc-end database. In one such embodiment, the cunent invmtion requires 
specification at access time of M^iether read-only, forward-only, or other specific access logic 
applies. 

Following is an illustrative application example. An appUcation developer is asked 
to create a system that will allow audiors to chedc sales of tfieir books at a store-l^-store 
basis. The enterprise for vMch the qiplication developer works has recent^ gone through 
a series of acquisitions, whidi have resulted in ftc enterprise having two Oracle systems for 
two of the enterprise's stores, and an SQL Server system. All of these systems are accessible 
through a Wide Area Network (WAN). In addition, the enterprise has extranet-style access 
to two additional stores through secure web servers ova: the Internet. 

When an auAor requests infonnation about the author's bode sales, the author wants 
the q)plication system to provide a single, unified user interfece wifli a single, unified view 
of the data. An online report that provides die author/user widi a table showing two columns, 
one column identifying each store, and the second column identifying the number of books 
by that author sold by that store would provide the author/user with the information requested. 
The online table report would further report a total at the bottom of the second column. Some 
authors will check sales over the Internet; others will use a vnreless device to check sales. 
In order to fecilitate these different devices, the requests and reqwnses are all encoded as 
XML. In this illustrative example, a combination of Active Server Pages and XSL (XML 
Stylesheet Language)are used to determine the cUent type and generate the appropriate WML 

(Wireless Markup LanguageyWAP (Wireless Access Protocol) orHTML/HTTP code fi)r the 

client device. 

Without the present invention, die ^plication developer must first idoitifies a unified 
XML layer that will return the appropnate XML r^ardless of \»*idi database or web server 
that supplies the data. Then, for each back-end, the qiplication developer must create a web- 
page to extract the iqppropriate data fiom the corresponding back end, constnictii^ XML as 
needed. These back-end access web pages can be used in odier projects. Then, the 
qiplication developer must create the web page that performs die work to load the ^propriate 
results using the intermediate web pages described above to retrieve the data, and to then 
consolidate the data bto a consoUdated XML object This working web page has a single 
input format and a single XML grammar for the outputs. Finally, the application developer 
must program the page to identify the type of client and invoke die appropriate XSL style 
sheet to perform the appropriate conversion for display of Ae uiformation fat the particular 
client device. 

Each back-end has a different access strategy. Oracle and SQL Server are not totally 
uniform. ADO provides some consistency. However, to obtain maximum performance. 
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differences in how things are accessed can be a factor. Each server may have different 
databases, security, tables, and columns. Some of the sources are not even databases, but are 
web servers. Web page server may provide XML or HTML. The application developers, in 
addition to knowing the application domain and Visual Basic, must also know ADO, SQL, 
and XML progranuning, including using DOM. 

The present invention provides a special server extension (portal) that allows 
application developers to treat databases and web servers as DOM trees. For the example 
author information request illustrated above, the following illustrative representation is 
provided: 

<myEntcrprise> 

<views> 

<viewname="SqlServerView"type="ADO" ...> 
<<:atalogs> 

<pubs> 

<titles> 



</titles> 
<ypubs> 
</catalogs> 
</view> 

<viewname="OracleABC' type="ADO" ...> 
<catalogs> 

<pubs> 

<titles> 



</title^ 
<pubs> 
</catalogs> 
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</view> 

<viewname="OracleABC" type="ADO" ...> 
<catalog^ 

<pubs> 

<titles> 

</titles> 

<^ubs> 
</catalogs> 
<Adew> 

<view name="Webr type="HTML" ...> 
^ages> 

<getTitles.jhtml> 
<title^ 

</titles> 
<ygetTitles.jlitm> 

</pages> 
</view> 

<viewiiame="Web2"lype="XML" ...> 
<pages> 

<getTitles.asp> 
<di]es> 

■ • • 
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</getTitles.asp> 
<;/pages> 
<Adew> 
</vicws> 
<myEnterprise> 

In this example, for titles, there is always an authjd field element Using the node 
path syntax previously described above, the following example metfiods woiild retrieve all 
titles rows for which the authjd attribute has a value of "123": 

L) sctobjBi2Collectioff= 

objBizIX)MPlus4uery(7/titles/row[@authJd=='1231") 

or, 

2.) For Each objBizNode in 
objBizDOMPlusJcqueiy(7/titles/row[@authJd==^123']") 

' do something with it 

Next 

If the target sources do not share the same field names, the method would need to use 
an **of ' predicate to find the appropriate values. An SQL Query or filter is applied to return 
a result if it is determined from metadata that the appropriate fields exist to support the query. 

A fiilly qualified XPath is used in some embodiments to retrieve the results from a 
specific data source so that other data sources do not have to be opened and checked. In one 
embodiment, the current invention instantiates a connection, only as needed, and utilizes OLE 
DB resource pooling, where available, to achieve maximum performance and scalability. 

Business application programmer/developers trying to integrate Ime-of-business 
Legacy systems with net market transactions are faced with baniers including varied data 
access programming models, different data structures, and varied data types. In the 
exemplary embodiment of the mvention, a data integration server is programmed to provide 
access to Line-Of-Business Legacy data firom such sources as RDBMS, HTTP, FTP, COM, 
CORBA and others; the server is programmed to use Intemet standards. The exemplary 
embodiment provides eBusiness application developers with the ability to leverage W3C 
Industiy standards to integrate varied data sources by providing a unifonn model of data 
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representation, a uniform data access programming model, and uniform datatyping. 

Relational Database Management systons (RDBMS) have a common logical 
structure, which has been powerfully abstracted by existing database middleware products. 
FIG. 46 depicts an exemplary tree representation of an exemplary RDBMS configuration. 

The current invention can instantiate a tree from any single node in the larger tree. 
For purposes of the following description of the invention, •Mrtualized" refers to a portion 
ofa DOM tree that is supplied by a data source, "instantiate** means Ae act of creating Ae 
relevant portion of the DOM tree in memory, •'serialize*' means the act of writing virtualized 
portions of data back to the data source. 

The current invention provides sub-tree instantiation by providing the user with the 
option of deciding at which point in the tree, the tree is to be mstantiated. 

The current invention further provides a virtual in-memory tree and virtual 
instantiation. The user asks for a property of a current node. The current invention checks 
the status of the current node and reports the status as: 1 .) it is from a static layer currently in 
memory; or 2.) it represents a layer that is supplied by a data source and is a.) currently in 
memory; or b.) it is not in memory at which point the current invention reads the node and 
loads it into memory. 

The current invention manages node write-back. When a progranuner performs 
method calls that create nodes in areas of the Virtual DOM tiiat are virtualized, the current 
invention instantiates the virtualized portion of the Vutual DOM. When a virtualized portion 
of the virtualized DOM is instantiated, the current invention sets flags to indicate for each 
node, whether the data has been changed. Each flag has four possible stales: ''O- represents 
No Change; "r represents New; *'2" represents Changed; and "3" represents "Deleted**. The 
values (M are illustrative and not a limitation of the invention. 

The current invention provides a serialize method and a discardChanges method. The 
serialize method starts a transaction that serializes changes to the data source and commits 
the transaction. When the serialize method is used, only the relevant nodes are written out 
In the exemplary embodiment, references to writeable nodes are kept in a hash table for high- 
speed access at write time. 

The discardChanges method returns the in-memoiy tree to its pre-change status. To 
support the discardChanges method, when a node is first changed, the current invention saves 
the original values in an "invisible" subtree. When a discardChanges method is issued, the 
current mvention retrieves the original values from the "invisible** subtree and rq>laces the 
original values in the.node. 
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When a node is deleted, the current invention sets the node's status to "invisible'*. 

When a new node is requested, the current invention creates a new node. 

In an alternative embodiment, the current invention starts a transaction and then 
allows ail changes to write to the data source. In this embodiment, whra the serialize method 
is used, the current invention then commits the transaction. In this embodiment, the 
discardChanges method simply rolls back the transaction. 



ILLUSTRATIVE EMBODIMENTS 

Although this invention has been described in certain specific embodiments, many additional 
modifications and variations would be apparent to those skilled in the art It is, therefore, to 
be understood that this mvention may be practiced otherwise than as specifically described. 
Thus, the embodiments of the invention described herem should be considered in all respects 
as illustrative and not restrictive, the scope of the invention to be determined by the appended 
claims and their equivalents rather than the foregoing description. 
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1. A method using a computer for converting source data to an Internet data 
structure, wherein said source data is characterized by a particular stnicture and by a set of 
relationships, wherein the structure and the set of relationships are described by metadata, and 
vtiierem said metadata comprises a plurality of metadata components, and wherein said 
metadata and said metadata components are accessible by said computer, and wherein said 
Internet data structure is characterizable by a tree-based structure definition, the method 
comprising: 

translating the metadata into a set ofDTD declarations and a corresponding tree-based 
structure definition, wherein said tree-based structure definition comprises a plurality of node 
definitions and wherein each DTD declaration is equivalent to one of said metadata 
components and wherein each of said node definitions is equivalent to one of said metadata 
components; 

storing as one of a plurality of conversion map components each equivalent 
docummt type definition declaration and tfie corresponding metadata component; 

storing as one of a plurality of conversion map components each equivalent node 
definition and the corresponding metadata component; 

aggregating the conversion map components into a conversion m^; and 

mapping the source data into the Internet data structure according to the conversion 

map. 

2. A computer system programmed for converting source data to an Intemet data 
structure, wherein said source data is characterized by a particular structure and by a set of 
relationships, wherein the structure and the set of relationships are described by metadata, and 
wherein said metadata comprises a plurality of metadata components, and wherein said 
metadata and said metadata components are accessible by said computer, and wherein said 
Intemet data structure is characterizable by a tree-based structure definition, the computer 
system comprising: 

program code for translating the metadata into a set of document type definition 
declarations and a corresponding tree-based structure definition, wherein said tree-based 
structure definition comprises a plurality of node definitions and wherein each document type 
definition declaration is equivalent to one of said metadata components and wherein each of 
said node definitions is equivalent to one of said metadata components; 
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program code for storing as one of a plurality of conversion map components each 
equivalent document type definition declaration and the corresponding metadata component; 

program code for storing as one of a plurality of conversion map components each 
equivalent node definition and the corresponding metadata component; 

program code for aggregating the conversion map components into aconversion map; 

and 

program code for mapping the source data into the Internet data structure according 
to the conversion map. 

3. A method using a computer of converting source legacy data to an Intemet 
data structure, the method comprising: 

converting the source legacy data to a mariced up electronic document; and 

using a marked up electronic document parser program to transform the mariced up 
electronic document to a machine readable tree-based format 

4. The method of claim 3 wherein the marked up electronic document is an XML 
document 

5. The method of claim 4 wherein the machine readable tree-based format is a 
Document Object Model. 

6. A method using a computer of converting source legacy data to an Intemet 
data stmcture, the method comprising: 

determining a plurality of relationships between the source legacy data and the Intemet 
data structure; and 

converting the source legacy data to a marked up electronic document according to 
the determined relationships. 

7. The method of claim 6 wherein the mariced up electronic document is marked 
up with tags, elements and attributes that reflect the data and flw mtent of the content of Ae 
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8. The method of claim 7, the method further comprising: 

accepting as input the marked up electronic document; and 

producing as output the content of the marked up electronic document in machine 
readable tree-based form. 

9. A method using a computer of converting source legacy data to an Internet 
data structure, the method comprising: 

converting the legacy data to an XML document; and 

using an XML parser to transform the XML document to a machine readable tree- 
based DOM. 

10. A method using a computer of converting source Internet data to a legacy data 
structure, the method comprising: 

determining aplurality of relationships between the source Internet data and the legacy 
data structure; and 

converting the source Internet data to the legacy data structure. 

11. The method of claim 10 wherein the converted Internet data m the legacy data 
structure reflects all of the data and the intent of the content of the source Internet data. 

12. A method using a computer of integrating an Intmiet data source with legacy 
data structures, the method comprising: 

converting the Internet data source to a simple legacy data structure wherein said 
source Internet data is in the form of a machine readable tree-based document object; and 

mtegrating the converted Intemet data into the legacy data structure. 
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13. The method of claim 12 wherein said Internet data source is in the fonn of a 
machine readable tree-based Document Object Model. 



1 4. The method of claim 1 3 wherein said Document Object Model has a plurality 
of nodes* said nodes arranged according to a tree-based hierarchy, each level of said hierarchy 
having associated with it a unique delimiter. 

15. A method using a computer of integrating a first source of Internet data having 
a first data structure wherein said first data structure having a plurality of data fields and 
wherein each data field of said first data structure having a tag name, with a second source 
of Intemet data having a second data structure wherein said second data structure having a 
plurality of data fields and wherein each field having a tag name, the method comprising: 

identifying each data element in said first data structure that corresponds to at least 
one data field in said second data structure; and 

renaming each data element in said first data structure with the name of the 
corresponding data field in said second data structure. 

16. The method of claim 15 fiirther comprising: 

building a record comprising data from said renamed first data structure; and 

labeling each data element in the record with the conesponding name of the 
corresponding data field in the second data structure. 

17. The method of claim 16 fiirther comprising the step of: 
posting the record to said second data structure. 

18. The method of claim IS v^erein the renammg step is accomplished using a 
Windows Scripting Hosted language. 

19. The method of claim 18 wherein the V^ndows Scripting Hosted language is 
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Visual Basic Script 
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20. The method of claim 1 8 wherein the Windows Scripting Hosted language is 
JavaScript. 

2 1 . The method of claim 1 8 wheiein the Windows Scripting Hosted language is 
PerlScript 

22. A method using a computer of converting source Internet data to a simple 
legacy data structure wherein said source Internet data is in the form of a machine readable 
tree-based Document Object Model with a plurality of nodes said nodes arranged according 
to a tree^based hierarchy, each level of said hioarchy having associated with it a unique 
delimiter, the method comprising: 

identifying a root node of the Document Object Model; 

traversing each child level node immediately subordinate to the root node; 

traversing every node subordinate to each diild node before proceeding to the next 
child node; 

inserting all of the data fields contained in each node subordinate to each child node 
into the simple legacy data structure; and 

inserting into the simple legacy data structure a delimiter for each data field. 

23. A method using a computer of converting source legacy data to an Internet 
data structure, wherein said source legacy data is comprised of one or more records of data, 
each record comprismg a first hierarchical level of data wherein said first hierarchical level 
of data comprises at least one subordinate hierarchical level of data, wherein each hierarchical 
level of the source legacy data contains at least one data field, wherein a plurality of 
successively hierarchical levels in the Internet data structure have been defined and wherein 
for each of said Internet data hierarchical levels, a unique start-of-data name tag and a unique 
end-of-data name tag have been assigned, for each source legacy data record the method 
comprising: 

initializing an output conversion record; 
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inserdng in die conversion record die unique start-of-data name tag for die first 
Internet data hierarchical level; 

identifying a next successive hierarchical level within the said source legacy data 

record; 

idratifying a hierarchical level from among the Internet data hierarchical levels that 
is equivalent in hierarchy level to the source legacy data hierarchical level; . 

inserting in the conversion record the unique start-of-data name tag of the 
corresponding Internet data hierarchical level; 

identifying each data field contained in the source legacy data hierarchical level; 

transferring all of the data fields contained in the source legacy data hierarchical level 
to the conversion record immediately following the unique start of data name tag of the 
corresponding Internet data hierarchical level; 

inserting in the conversion record the unique end of data name tag of the 
corresponding Internet data hierarchical level; and 

repeating the steps until all of the data contained in the legacy data record has been 
converted. 

24. A method of converting source data structured according to a simple data 
structure to a tree-based rich data structure, whereui said source data is comprised of one or 
more records of data, each record comprising a first hierarchical level of data >^erein said 
first hierarchical level of data comprises at least one subordinate hierarchical level of data, 
the method comprising: 

identifying each hierarchical level within said source data; 

for each of said source data hierarchical levels, creating an element level node in said 
target data structure corresponding to said source data hierarchical level; 

for each of said source data hierarchical levels, identifying all items of source data 
\(4ierein said souice data is directly associated with said source data hierarchical level; and 

for each of said source data hierarchical levels, saving in said target data structure all 
of said identified items of data directly associated with said source data hierarchical level and 
designating said saved data as being associated with said corresponding target data element 
level node. 



-94- 



wo 01733387 



PCT/CAOO/01280 



25. A method using a computer of converting source data structuied according to 
a simple data structure to target data stored structured according to a tree-based data structure 
having at least one relational node, the method comprising: 

creating a first node in said target data store; 

identifying at least one key level within said source data; 

for each of said source key levels, creating a node in said target data coiresponding 
to said source k^ level; 

associating each created node in said target data with at least one other node in said 
target data store; 

for each of said source key levels, identifying all items of data wherein said data is 
directly associated with said source key level; 

for each of said source key levels, describmg all items of data directly associated witfi 
said source key level in terms of said target data node; and 

for each of said source key levels, saving in said target data store all said described 
items of data directly associated with said source key level in terms of said target data node. 

26. A computer system for converting source data to an Intemet data structure, 
wherein said source data is characterized by a particular structure and by a set of relationships, 
wherein the structure and the set of relationships are described by metadata, and wherein said 
metadata comprises a plurality of metadata components, and wherein said metadata and said 
metadata components are accessible by said computer, and wherein said Intemet data 
structure is characterizable by a tree-based structure definition, the computer system 
progranmied to: 

translate the metadata into a set of document type definition declarations and a 
corresponding tree-based structure definition, wherein said tree-based structure definition 
comprises a plurality of node definitions and herein each document type definition 
declaration is equivalent to one of said metadata components and ^^erein each of said node 
definitions is equivalent to one of said metadata components; 

store as one of a plurality of conversion map components each equivalent document 
type definition declaration and the corresponding metadata component; 

store as one of a plurality of conversion map components each equivalent node 
definition and the corresponding metadata component; 
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aggregate tiie conversion map components into a conversion miq>; and 

convert the source data into the Internet data structure according to the conversion 

map. 

27. A computer program product having instnictions for 

converting without data loss a legacy data source to a tree-based Internet data 
structure; and 

integrating without data loss said converted legacy data with an existing Internet data 
source, said existing Internet data source having a tree-based Internet data structure . 

28* A computer program product having instructions for: 

converting widiout data loss an Internet data source having a tree-based Internet data 
structure to a simple data structure; and 

integrating without data loss said converted Internet data with an existmg legacy data 
source, said legacy data source having a simple data structure. 

29. A computer program product having instructions for 

e)q)osing the abi 1 ity to execute a method on a Legacy Line-of-Business database sender 
using an Internet application on a Web server; and 

returning the results of the executed method to the Web server as an Internet data 
structure. 

30. A computer program product having instructions for: 

wrapping a first Document Object Model with a second Document Object Model. 

3 1 . The computer program product of Claim 30 having further instnictions for: 

exposing to the second Document Object Model a plurality of properties and a 
plurality of methods which define a plurality of aspects of said first Document Object Model. 
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32. A computer program product having instructions for 

creating a first Document Object Model with a first class definition as a template for 
a second Document Object Model; and 

creating the second Document Object Model with a second class definition. 

33. The computer program product of Claim 32 having fiirther instructions for. 

replacing the second class definition of the second Document Object Model with the 
first class definition of the first Document Object Model. 

34. The computer program product of Claim 33 having fiirther instructions for 
loading the first Document Object Model into the second Document Object Model. 

35. The computer program product of Claim 34 havmg fiirther instructions for 

ejcposing to the second Document Object Model a plurality of properties and a 
plurality of methods which define a plurality of aspects of said first Document Object Model. 

36. The computer program product of Claim 35 having fiirther instructions for: 

e3q)0sing to the second Document Object Model a plurality of data items contained 
within said first Document Object Model. 

37. The computer program product of Claun 35 having fiirther instructions for 

operating on the second Document Object Model to determine a value for at least one 
of said exposed properties. 

38. The computer program product of Claim 35 having fiirther instructions for 

operating on the second Document Object Model to establish a value for at least one 
of said exposed properties. 
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39. The computer program product of Claim 35 having further instructions for 

operating on a method that controls an aspect of the second Document Object Model 
to control an aspect of the first Document Object Model. 

40. The computer program product of Claun 36 having further instructions fon 

operating on the second Document Object Model to add a data item to said first 
Document Object Model. 

41 . The computer program product of Claim 36 having further instructions for: 

operating on the second Document Object Model to remove a data item from the data 
contained within said first Document Object Model. 

42* The computer program product of Claim 36 having fiirfher instructions for: 

operating on the second Document Object Model to modify a data item contained 
within said first Document Object Model. 

43 . The computer program product of Claim 36 having further instructions for 

operating on the second Docimient Object Model to retrieve a data item contained 
within said first Document Object Model. 

44. The computer program product of Claim 36 having fiirther instructions for: 

exposing to the second Document Object Model a plurality of structural elements 
contained within said first Document Object Model. 

45. The computer program product of Claim 44 having fiirttier instructions for 

operating on die second Document Object Model to add a structural element to said 
first Document Object Model. 
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46. The computer program product of Claim 44 having further instructions for 

operating on the second Document Object Model to remove a structural element from 
the structural elements contained within said first Document Object Model. 

47. The computer program product of Claim 44 having fiirther instructions for: 

operating on the second Document Object Model to modify a structural element 
contained within said first Document Object Model. 

48. The computer program product of Claim 44 having further instructions fi)r: 

operating on the second Document Object Model to retrieve a structural element 
contained within said first Document Object Model. 

49. The computer program product of Claim 44 having further instructions fi>n 

operating on the second Document Object Model to retrieve a collection of a plurality 
of structural elemmts contained within said first Document Object Model. 

50. The computer program product of Claim 44 having finlfaer instructions for 
specifying a name to the second Document Object Model; 

operating on die second Document Object Model to identify a component of said first 
Document Object Model as a particular property, method, data item or structural component 

51. A computer program product for providing a browser Q-Pointer interface 
having instructions for: 

receiving mput from a user containing new Q-Pointer information for an existing file; 

and 

tying said user input Q-Pointer information to said file. 



52. A computer program product for providing a browser Q-Pointer mterfece 
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having instructions for 

reporting to a user a plurality of Q-Pointer information for at least one existing file* 



S3. The computer program product of Claim 52 having furtfier instructions for: 
receiving input from a user for modifying said Q«Pointer infomoation. 



54. A computer program product for accessing a set of hierarchical data using a 
global conunimications network server programming environment, said computer program 
product having instructions for: 

establishing a browser inter&ce connection; 

retrieving a file name variable; 

retrieving a filter text value; and 

retrieving said set of hierarchical data using said file name variable and said filter text 

value. 

55. A computer system programmed for accessing and integrating electronic data, 
said computer system programmed to: 

wrap a first Document Object Model with a second Document Object Model. 

56. The computer system of Claim 55 further programmed to: 

expose to the second Document Object Model a plurality of properties and a plurality 
of methods which define a plurality of aspects of said first Document Olgect Model. 

57. A computer system programmed for accessing and integrating electronic data, 
said computer system programmed to: 

create a first Document Object Model with a first class definition as a template for a 
second Document Object Model; and 
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create the second Document Object Model with a second class definition. 



58. The computer system of Claim 57 further programmed to: 

replace the second class definition of the second Document Object Model with the 
first class definition of the first Document Object Model. 

59. The computer system of Claim 58 fiirttier programmed to: 

load the first Document Object Model into the second Document Object Model. 

60. The computer system of Claim 59 fiirther programmed to: 

expose to the second Document Object Model a pliirality of properties and a plurality 
of methods which defme a plurality of aspects of said first Document Object Model. 

61. The computer system of Clahn 60 fiirdier programmed to: 

expose to the second Document Object Model a plurality of data items contained 
within said furst Document Object Model 

62. The compute system of Claim 60 fiirther programmed to: 

operate on the second Document Object Model to determine a value for at least one 
of said exposed properties. 

63. The computer system of Claim 60 fiirther programmed to: 

operate on the second Document Object Model to establish a value for at least one of 
said exposed properties. 

64. The computer system of Ciaun 60 fiirther progranuned to: 

operate on a method that controls an aspect of the second Document Object Model to 
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65. The computer system of Claim 60 further programmed to: 

operate on the second Document Object Model to add a data item to said first 
Document Object Model. 

66. The computer system of Claim 6 1 fiirtfaer programmed to: 

operate on the second Document Object Model to remove a data item fiom the data 
contained within said first Document Object Model. 

67. The computer system of Claim 61 further programmed to: 

operate on the second Document Object Model to modify a data item contained vdtfain 
said first Document Object Model. 

68. The computer system of Claim 61 further progranuned to: 

operate on the second Document Object Model to retrieve a data item contained 
within said first Document Object ModeL 

69. The computer system of Claim 61 further programmed to: 

expose to the second Document Object Model a plurality of structural elements 
contained within said first Document Object Model. 

70. The computer system of Claim 69 further programmed to: 

operate on the second Document Object Model to add a structural element to said first 
Document Object Model. 

71 . The computer system of Claun 69 further programmed to: 
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operate on the second Document Object Model to remove a structural element from 
the structural elements contained within said first Document Object Model 

72« The computer system of Claim 69 further programmed to: 

operate on the second Document Object Model to modify a structural element 
contained within said first Dociunent Object ModeL 

73. The computer system of Claim 69 fiuther programmed to: 

operate on the second Document Object Model to retrieve a structural element 
contained within said first Document Object Model. 

74. The computer system of Claim 69 finrther programmed to: 

operate on the second Documrat Object Model to retrieve a collection of a plurality 
of structural elements contained within said first Document Object Model. 

75. The computer system of Claim 69 fiuther programmed to: 
specify a name to the second Document Object Model; 

operate on the second Document Object Model to identify a component of said first 
Document Object Model as a particular property, method, data item or structural componoit 

76. AcomputersystemforprovidiiigahrowserQ-Pointerintafiice,saidcomputer 
system programmed to: 

receive input from a user containing new Q-Pointer information for an existing file; 

and 

tie said user input Q-Pointer information to said file. 

77. A computer system for providing a browser Q-Pointer inter&ce, said computer 
system programmed to: 
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iq>ort to a user a plurality of Q-Pointer infoimation for at least one existing file. 

78. The computer system of Claim 77 further programmed to: 
receive input from a user for modifying said Q-Pointer information. 

79. A computer system for accessing a set of hierarchical data using a global 
communications network server programming environment, said computer systm 
programmed to: 

establish a browser interfece connectiol^ 

retrieve a file name variable; 

retrieve a filter text value; and 

retrieve said set of hierarchical data using said file name variable and said filter text 

value. 

80. A methdd using a computer fi>r accessing and integrating electronic data, said 
method comprising: 

creating a first Document Object Model with a first class definition as a template for 
a second Document Object Model; and 

creating the second Document Object Model with a second class definition. 

8 1 . The method of Claim 80 fiirdier comprising: 

replacing the second class definition of the second Document Object Model with the 
first class definition of the first Document Object Model. 

82. The metiiod of Claim 81 fiirtiier comprising: 

loading tiie first Document Object Model into the second Document Object Model. 
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83. The method of Claim 82 further conqnising: 

exposing to the second Document Object Model a plurality of properties and a 
plurality of methods which define a plurality of aspects of said first Document Object Model. 

84. The method of Claim 83 further comprising: 

exposing to the second Document Object Model a plurality of data items contained 
within said first Document Object Model. 

85. A method using a computer for providing a browser Q-Pointer inter&ce, said 
method comprising: 

receiving input firom a user containing new Q-Pointer information for an existing file; 

and 

tying said user input Q-Pointer mformation to said file. 

86. A method using a computer for providing a browser Q-Pointer interfece, said 
method comprising: 

reporting to a user a plurality of Q-Pointer information for at least one existing file. 

87. The method of Claim 86 further comprising: 

receiving ir^ut fix>m a user for modifying said Q-Pointer information. 

88. A method using a computer for accessing a set of hierarchical data using a 
global cornmunications network server programming environment, said method comprising: 

establishing a browser inter&ce connection; 

retrieving a file name variable; 

retrieving a filter text value; and 

retrievi ng said set of hierarchical data using said file name variable and said filter text 

value. 
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89. A computer system for accessing and integrating electronic data, said computer 
system comprising: 

a set of program instructions for creating a first Document Obj ect Model with a first 
class definition as a template for a second Document Object Model; and 

a set of program instructions for creating the second Document Object Model with a 
second class definition. 

90. The computer system of Claim 89 fiirther comprising: 

a set of program instructions for replacing the second class definition of the second 
Document Object Model with the first class definition of the first Document Object Model. 

91 . The computer system of Claim 90 fiirther comprising: 

a set of program instructions for loading the first Document Object Model into the 
second Document Object Model. 

92. The computer system of Claun 91 fiirtfier comprising: 

a set of program instructions for exposing to the second Document Object Model a 
plurality of properties and a plurality of methods which define a plurality of aspects of said 
first Dociunent Object Model. 

93. The computer system of Claim 92 fiirdier comprising: 

a set of program instructions for exposing to the second Docxmient Object Model a 
plurality of data items contained within said first Document Object Model. 

94. Acomputer systanforproviding abrowserQ-Pointer interface, said computer 
system comprising: 

a set of program instructions for receiving input horn a user containing new Q-Pointer 
information for an existing file; and 

a set of program instructions for tying said user input Q-Pointer information to said 
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95. A con^uter system for pmvidingabrowserQ-Pointer mterface,saidooinputer 
system comprising: 

a set of program instructions for reporting to a user a plurality of Q-Pointer 
information for at least one existing file. 

96. The computer system of Claim 95 further comprising: 

a set of (Hogram instructions for receiving input fix)m a user for modifying said Q- 
Pointer information. 

97. A computer system for accessing a set of hierarchical data using a global 
communications network server programming environment, said computer system 
comprising: 

a set of program instructions for establishing a browser interface connection; 

a set of program instructions for retrieving a file name variable; 

a set of program instructions for retrieving a filter text value; and 

a set of program instructions for retrieving said set of hierarchical data using said file 
name variable and said filter text value. 

98. A computer program product for providing a Document Object Model 
language syntax with which to link multiple programming activities in a single line of coding, 
said computer program product having instructions for: 

performing a first program instruction on an object; 

returning as a value the object upon which the program instruction was performed; 
making said object value available to a second program instruction. 

99. A method using a computer of converting a plurality of legacy data sources to 
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a imifonn model of data representation, the metfiod comprising: 

representing each legacy data source as a virtual in-memory tree-based data structure. 



100. A computer system for converting a plurality of legacy data sources to a 
uniform model of data representation, the computer system comprising: 

a set of program instructions for representing each legacy data source as a virtual in- 
memory tree-based data structure. 

101. A computer system for converting a plurality of legacy data sources to a 
uniform model of data representation, said computer system programmed to: 

rqpiresent each legacy data source as a virtual in-memory tree-based data structure. 

1 02. A computer program product for converting a plurality of legacy data sources 
to a uniform model of data repres^tation, the computer program product having instructions 
fon 

representing each legacy data source as a virtual in-memory tree-based data structure. 

103. A method for processing a document, comprising: 

providing at least one process document including processing iristructions; 
accepting an incoming document; 

reading a server document, the s^er document including process document 
selection instructions for selecting aprocess document based on the incoming 
document; 

selectmg a process document using the server document process document 
selection instructions and the incoming document; and 

processing the incoming document according to the processing instructions 
in the selected process document. 

104. The metiiod of Claim 103 wherein: 

the server document is a XML document; and 
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the selected process document is a XML document 

105. The method of Claim 103, wheiein the selected process docummt processing 
instructions further include incoming document to working document translation 
instructions, 

106. The method of Claim lOS, wherein the selected process document processing 
instructions further include: 

working document to transmission document translation instructions; and 

transmitting instructions for transmitting the transmission document via a 
communication network. 

107. The method of Claun 103, further comprising transforming the incoming 
document into an incoming software object 

108. The method of Claim 107, wherein the selected process document processmg 
instructions further include invoking a document processing software object 

109. A method for processing a document received fiom a client via a communication 
network, comprising: 

providing at least one process document including processiiig instructions; 
providing at least one translation document; 

receiving an incoming document from the client via the conmiunication 
network; 

reading a serv^ document, the server document including: 

process document selection instructions for selecting a process 
document based on the incoming document; and 

translation document selection instructions for selecting a translation 
dociunent based on the incoming document; 

selecting a translation document using the server document translation 
document selection instructions and the incoming document; 

translating the incoming document into a working document using the 
selected translation document; 

selecting a process document using the server docimient process document 
selection instructions and the incoming document; and 
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processing the woiking document according to the processing instructions in 
the selected process document 

1 10. The method of Claim 109, wherein the selected process document processing 
instructions further include transmitting instructions for transmitting the woiking 
document via the communication network. 

111. The method of Claim 109, wherein the selected process document processing 
instructions further include: 

working document to transmission document translation instructions; and 

transmitting instructions for transmitting the transmission document via the 
communication network. 

112. The method of Claim 109, further comprismg transforming the working 
I ^ document into a working software object 

113. The method of Claim 109, further comprising transforming the incoming 
document into an incoming software object 

1 14. The me&od of Claim 109, vvdieiein the selected process document processing 
20 instructions further include invoking a document processing software object 

lis. The method of Claim 109 \^ecein: 

the serving document is an XML document; and 

the selected process document is a XML document 

25 

1 16. The method of Claim 109 wherein: 

the incoming document is an XML document; 

the woridng document is an XML document and 

the selected translation document is a XSLT document 

1 17. A data processing system adapted to process documents received from a client 
via a cooomunication network, comprising: 

a processor; and 

a memory operably coupled to the processor and having program instructions 
stored therein, the processor being operable to execute the program 
instructions, the program instructions including: 
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pipeline instnictions, the pipeline instructions including: 

receiving an incoming document sent by the clirat via the 
communications network; 

invoking a sorter, the sorter containing instructions, the 
instructions including selecting processing instructions for the 
incoming document; and 

invoking a dispatcher, the dispatcher containing instructions, 
the instructions including processing the incoming document 
according to the selected processing instructions. 

118. The data processing system of Claim 1 17, the processing instructions further 
including transmitting a document to the client via die communication network. 

1^ 119. The data processing system of Claim 1 18, the processing instructions further 

including transmitting a document to a server via the communication networic. 

1 20. A data processing system adapted to process a document, comprising: 

a processor; and 

2® a memory operably coupled to the processor and having program instructions 

stored therein, the processor being operable to execute the program 
instructions, the program instructions including: 

accepting an incoming document; 

25 reading a server docimient, the server document including process 

document selection instructions for selecting a process document 
based on the incoming document, the process document including 
processing instructions; 

3Q selecting a process docimient using the server document process 

document selection instructions and the incoming document; and 

processing the incoming document accordmg to the processing 
instructions in the selected process document 

35 121 . The data processing system of Claim 120 v^erein: 

the server document is a XML document; and 

the selected process documoit is a XML document 
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122. The dataprocessing system of Claim 120, vdieiein the selected process document 
processing instructions further include incoming document to working document 
translation instructions. 

1 23 . The data processing system of Claim 1 20, wherein the selected process document 
processing instructions further include: 

working document to transmission document translation instructions; and 

transmitting instructions for transmitting the transmission document via a 
communication network. 

124. The data processing system of Claim 120, the program instructions further 
including transforming tiie incoming document into an incoming software object 

1 25. The data processing system of Claim 1 20, wherein the selected process document 
processing instructions further include mvoking a document processing software 
object. 

126. A data processing system adapted to process a document sent from a client via 
a communication network, comi»ising: 

a processor, and 

a memory operably coiq>ied to the processor and having program instructions 
stored therein, the processor being operable to execute the program 
instructions, the program instructions including: 

receiving an incoming document sent by the client via the 
communication network; 

reading a server document, the server document including: 

process document selection instructions for selecting aprocess 
document based on the incoming document, the process 
document including processing instructions; and 

translation document selection instructions for selecting a 
translation document based on the incoming document; 

selecting a translation documrat using the server document translation 
document selection instructions and the incoming document; 

translating the incoming document into a working document using the 
selected translation document; 
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selecting a process document using the s^er document process 
document selection instructions and die incoming document; and 

processing the woridng document according to the processing 
instructions in the selected process document. 

127. The data processing system of Claim 126, wherein the selected process 
document processing instructions further include transmitting instructions for 
transmitting the working document via the communication networic. 

128. The data processing system of Claim 126, wherein the selected process document 
processing instructions further include: 

working document to transmission document translation instructions; and 

transmitting instmctions for transmitting the transmission document via the 
1^ communication network. 

129. The data processing system of Claim 126, the program instructions further 
comprising transforming the working document into a working software object 

130. The data processing system of Claim 126, the program instructions further 
2Q comprising transforming the incoming document into an incoming software object 

131. The data processing system of Claim 1 26, whereintiie selectedprocess document 
processing instructions further include invokmg a document processmg software 
object. 

25 132. The data processing system of Claim 1 26 wherein: 

the serving document is a XML document; and 
the selected process document is a XML document 

133. The data processing system of Claim 126 wherein: 
the incoming document is a XML document; 
the working document is a XML docinnent; and 
the selected translation document is a XSLT document 

134. A computer program product embodying computer program instructions for 
execution by a computer, the computer program instructions comprising: 

pipeline instructions, the pipeline instructions including: 
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receiving an incoming document sent by the client via the 
conununications networic; 

invoking asorter, the sorter containing instructions including selecting 
processing instructions for the incoming document; and 

invoking adispatcher, the dispatcher containmg instnictions including 
processing the incoming document according to the selected 
processing instructions. 

135. The con^uter program product of Claim 134, the processing instructions further 
including transmitting a document to the climt via the communication network. 

136. The con4)uter program product of Claim 134, the processing instructions further 
including transmitting a document to a server via the communication network. 

137. A compirter program product embodying computer program instructions for 
execution by a computer, the con^uter program instructions comprising: 

accepting an incoming document; 

reading a server document, the server document including process document 
selection instxuctionsfor selecting a process document based on the incoming 
document, the process document containing processing instructions; 

selecting a process document using the server docxmimt process docummt 
selection instructions and the incoming document; and 

processing the incoming docimient according to the processing instructions 
in the selected process document 

138. The computer program product of Claim 137 wherein: 

the server document is a XML document; and 
the selected process document is a XML document 

139. The computer program product of Claim 137, wherein the selected process 
document processing instructions further include incoming document to working 
document translation instructions. 

140. The computer program product of Claim 137, wherein the selected process 
document processing instructions furdier include: 

working document to transmission document translation instructions; and 
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transmitting instructions for transmitting the transmission document via a 
communication netwoik. 

141. ThecomputerprogramproductofClaim 137, the computerprogram instructions 
further comprising transforming the incoming document into an incoming software 
object 

142. The computer program product of Claim 137, wherein the selected process 
document processing instructions further include invoking a document processing 
software object 

143. A computer program product embodying computer program instructions for 
execution by a computer, the computer program instructions comprising: 

receiving an incoming document sent by the client via the communication 
netwoik; 

reading a server document, the server document including: 

process document selection instructions for selecting a process 
document based on the incoming document, the process document 
including processing instructions; and 

translation document selection instructions for selecting a translation 
document based on the incoming documoit; 

selecting a translation document using the server document translation 
document selection instructions and the incoming document; 

translating tiie incoming document into a working document using tiie 
selected translation document; 

selecting a process document using the server document process document 
selection instructions and the incoming docummt; and 

processing tiie woridng document according to tiie processing instructions in 
the selected process document 

144. The computer program product of Claim 143, wherein the selected process 
document processing instructions furtiier include transmitting instructions for 
transmitting tiie working document ^a the communication netwoik. 

145. The computer program product of Claim 143, v«iierein the selected process 
document processing instructions further include: 
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woridng document to transnussion docummt translation instructions; and 

transmitting instructions for tnumnitting the transmission document via the 
conmiunication networic 

146. Thecomputerprogramproductof Claim 143, the computer program instructions 
further comprising transforming the woridng document into a working software 
object 

147. The data processing ^stem of Claim 143, the computer program instructions 
further comprising transforming the incoming document into an incoming software 
object 

148. TTie computer program product of Claim 143, \;*icrcin the selected process 
document processing instructions further include invoking a document processing 
software otject 

149. The computer program product of Claim 143 wherein: 

the serving document is a XML document; and 
die selected process docurnent is a XML document. 

150. The computer program prodixt of Claim 143 wherein: 

the incoming document is a XML document; 

the working docummt is a XML document; and 

the selected translation document is a XSLT document 
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FIG. 9 



DETERMINE WHICH TABLE 
IS THE TOP-LEVEL TABLE 
IN THE RESULT- SE T. 



IDENTIFY THE NUMBER OF COLUMNS 
THE TOP-LEVEL TABLE HAS. 



SEARCH THE DTD TO DETERMINE THE 
NUMBER OF. AND TO DETERMINE THE 
IDENTITY OF. ELEMENTS WHICH DO NOT 
CONTAIN SUB-ELEMENTS OR ATTRIBUTES 
AND THAT CAN CONTAIN TEXT THAT 
EXIST. OR CAN EXIST. AS A CHILD 
ELEMENT OF THE ROOT ELEMENT. 



MATCH THESE LOWEST LEVEL ELEMENTS. 

ONE FOR ONE WITH RESULT- SET 
COLUMNS FROM THE TOP-LEVEL TABLE. 



FIND THE FIRST CHILD- TABLE 
AND COUNT IT'S COLUMNS. 



FIND AN ELEMENT THAT CAN BE 
REPEATED. WHICH HAS SUFFICIENT 
ELEMENTS OR ATTRIBUTES TO MATCH 
THE NUMBER OF COLUMNS IN THIS 
CHILD TABLE. 



I 



MATCH THESE REPEATABLE ELEMENTS. 
ONE FOR ONE. WITH THE RESULT-SET 
COLUMNS FROM THE CHILD- TABLE. 



REPEAT THIS PROCESS TO NTH. LEVEL 



REPEAT THIS PROCESS AT ANY LEVEL, 
FOR ALL CHILD TABLES AT THAT LEVEL 
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FIG. 15 



201a 



"^CRECORD ID="0G101"> 
''"-^FEILD> 1 1 24er <VFIELD:r'°* 
"'"'XFIELD> ABC </FIELD^'°' 



''^■^VALUE> XYZ </VALUE> 
^'^"^VALUE> XXX VVALUE^'"* 

'''■^/FIELD> ^^'^ 

'"">;FIELD> 



218 

">:VALUE> 

220-^\ / A I I 11-^ A ^'/v / A 1 I — 222 



'^VALUE> 1 </VALUE>^' 
'"■^/FIELD> 

'"'"^FIELD> ^226 j„ 

'"~<VALUE> 1495 </VALUE/" 
'^*~<VALUE> 995 </VALUE:<~'*' 

"'~</FIELD> ^229 

"'^FIELD> 

'^~<VALUE> ^235 236-^ 

*^~<SUBVALUE> BLACK </SUBVALUE> 
^^'~?CSUBVALUE> 220.V </SUBVALUE> 



M^v' w m m «m ^ » ^ M w - - — » 

2*0->:/VAHJE> ^238 239->' 




■241 
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FIG. 16 



_ -241 

'''">:VALUE> ^244 ^245 

243- 




'^SUBVALUE> RED,^<:/SUBVALUE> 
^*^'^:SUBVALUE> IICTV </SUBVALUE:$^' 
^*'^SUBVALUE> BATTFRY </SUBVALUE> 
^*^"^VALUE> 251--^ 
'""^FIELD> ^255 ^ 

'''*^VALUE> 1023 </VALUE:r 
'""^VALUE> 1076 </VALUE:r"' 
'•'°-^/FIELD> 
''"■5;FIELD> ^263 

'">:VALUE> 11243 </VALUE:r 
2«5-5;vALUE> 11267 </VALUE:r'" 
'^^"</FIELD> 
'*^^FIELD> 



271 

"°~<VALUE> 1000 </VALUE> 
*^^">;VALUE> 1480 </VALUE>^"^ 
"^"^/FIELD> ^274 



</RECORD> 



-277 
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FIG. 18 



•150a-1 



1500^3= "<jQOCTYPE MVDATA [" 
''*^=s&"<! ELEMENT MVDATA (RECORD*)>" 
'^■^s=s&"<! ELEMENT RECORD (#PCDATA)>" 
'^-s=s&"]" 

i50o^=s&"<MVDATA><REC0RD/></MVDATA>" 
'^'^ob j. load XM L( s)/-i5i.-i 

151b-^ ^ /■ — '52o 

"'•"obj.MVDATA.APPEND("foo") 

152d-^ — 152c — 152b 

'""^if obj.validate()then 

^ — 153o 

''^■"msgBox "DATA IS VALID" 

155-^|_2E 



"^■"msgBox "DATA IS NOT VALID 
'"^ND IF 
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1600--^ 

<MVDATA> 

<RECORD> FIG. 19 
<FIELD> 

I'M FIRST 
</FIELD> . 
<FIELD> 

NEW DATA 
</FIELD> 
</RECORD> 
</MVDATA> 

FIG.20 

<MVDATA XML:SPACE="PRESERVE"> 



^^^^<RECORD> 

^ ^167 

<FIELD> 

I'M FIRST- 

</FIELD>^^®^ 

^ ^162 

<FIELD> 3 

NEW DATA 
</FIELD> 
</RECORD> 
</MVDATA> 

^ — 166 
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1600-^ 



<MVDATA> 



<RECORD> 

^ — 162 

<FIELD> 63 
NEW DATA 
</FIEL^''' 

</recor5>^^^^ 

</MVDAT^ 



FIG. 22 



■160b /^160c yr—\Q06 
160a^\ / ^ ^ {/ ^ V 

<MVDATA XML:SPACE="PRESERVE"> 

. 161 

<REC0RD> 

^ — 162 

<FIELD> 3 
NEW DATA 

164 



</FIELD> 

</recor6>^^^^ 
</mvdat;G^^®® 
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\ /recordN / 
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•604 



601 \^ ^^0^ 
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/ 



■608 



•626 



FIELD ) ( FIELD ) ( FIELD ) • • • ( FIELD 



• • • 



FIELD 



;^05 



loe: 



11246 ABC 



613- 

•611 



607 



627- ^629 

(value) (value] 



(VALUE) (VALUE 



609- 



1000 1480 



XXX 



-614 



XYZ 

610-^ 612-^ 

(value; 

■617 >C^^22 
^6 2 Ox^ 2 4 

SUBA ASUB\ /SUB\ /SUb\ ?SUB 
^ALUEj WALUEJ VVALUEj VVALUEj \yALUEj 

616-^ 



615- 



BLACK 220V RED 110V BATTERY 



618 



^ 621-^ 623^ 625^ 
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FIG. 24 



INSTRUCT ADAPTER 
TO LOOK FOR 
LOGIN PROMPT 



I 



WAIT UP TO 4 SECONDS 
FOR ADAPTER TO RESPOND 
BEFORE PROCEEDING 



I 



SEND LIBOLEDB STARTUP 
FOLLOWED BY LOCATION 
TO WHICH TO CONNECT 
AND A CARRIAGE RETURN 



I 



INSTRUCT ADAPTER TO 
WAIT FOR PASSWORD 
PROMPT 



I 



WAIT UP TO 2 SECONDS 
FOR ADAPTER RESPONSE 
BEFORE PROCEEDING 

\ ~7 



SEND PASSWORD FROM 
PASSWORD PROPERTY 
FOLLOWED BY A 
CARRIAGE RETURN 
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FIG. 27 
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FIG. 28 



400— PRIVATE SUB C0MMAND1_CLICK() 

401- -DIM OBJMVD AS NEW GAXLIB.MVDOM 

402— OBJMVD.CREATEROOT ("MVDATE").APPEND("RECORD"). 

403— APPENDATTRIBUTE("ID")="ABC" 

404— OBJMVD.MVDATA.APPENDC'RECORD"). 

405— APPENDATTRIBUTE("ID")="DEF" 

406— OBJMVD.MVDATA.APPENDC'RECORD") 

407— APPENDATTRIBUTEC'ID") = "GHI" 

408— OBJMVD.MVDATA.APPEND("FOO") = "BAR" 

409 — FOR EACH RECITEM IN OBJMVD.MVDATA.CHILDNODES() 
Ain-J'MSGBOX RECITEM.NAME. . _ 

41 u—^ "FOR EACH WITH CHILDNODES()" 

411— NEXT 

fFOR EACH RECITEM IN 

\ OBJM VD.M VDATA.CHILDNODESC'RECORD") 
>iit-J'MSGBOX RECITEM.NAME, . _ 

"FOR EACH WITH CHILDNODESC'-RECORD"")" 

414— NEXT 

415— DIM OBJMVCOLL AS NEW GAXLIB.MVCOLLECTION 

416— SET OBJMVCOLL = OBJMVD.MVDATA.CHILDNODES() 

417— FOR I = 1 TO OBJMVCOLL.COUNT 

x.o JMSGBOX CSTR(i) «Sc & OBJMVCOLL. I TEM(i). 
'^^^n.NAME. . _ "LOOPING THROUGH USING ITEMS(n)" 

419 — NEXT 
419— END SUB 
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-311 



310---1- >LISTU (N ^337 
310- 

310-^" '_ PR#. PCBF NAME ATIME.. DATE LOCATION 

310- 



310 — ^0000 0400 LIBERTY 22:54 12/04/99 PROCESS 0 
310— -0016 0600 JOHN 12:59 11/30/99 PROCESS 16 

310-^-0017 0620 TIM 12:59 11/30/99 PROCESS 17 



FIG. 3 2 



350— <%®Languoge=VBScrlpt %> 
351-1 — <% 

352 — set obj=Server.Create0bject("Blz0bject.Bi2Adopter ) 

353 — obj.DataSource="dbms. myserver.com" 

354 — obj.Userld="ORDERENTRY" 

355 — obj.Password="MYPASSWORD" 

356 — x=obj.readXML("EXE TCL 'USTU (N'") 

357 — Response.ContentType=''text/xmr 

358 — Response.Write(xml) 
351-2 — %> 
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FIG. 4 2 

486 - — maxltems=100 

487 FileName=Request.QueryString("FileName") 

I IF FileName = Then 

488- -^ 

I FileNome=Request.Form.ltem("FileName") 

489 End if 

490 FilterText=Request.QueryString("FilterText") 



491 




f FilterText = then 

Filter Text=Request.Fornn.ltenn("FilterText") 



492 end if 



FIG A3 
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